DB엔지니어라면 코드를 몰라도 API서버가 만들어지는 것 같습니다.

영상버전 : https://youtu.be/JGgTOA5Tcsc

2007년에 SQL Server에 있는 SP를 기반으로 만든 서비스가 있습니다. 

다른 RDBMS에서는 그냥 프로시저라고 부르는데 유독 SQL Server에서만 Stored Procedure라고 하네요.. 

이유가 뭔지는 모르겠지만..

아뭏든.. 

거의 모든 처리는 SP에서 처리하고 

웹페이지는 그냥 SP를 실행한 결과만 호출하는 방식이죠.

결과 또한 표시 화면에 맞추어 쿼리를 만들었기 때문에 계산이나 변수에 받아서 조정할 일이 없습니다. 

여기에는 많은 개념이 있었는데요.. 

2007년이면 AWS가 막 이름을 내기 시작했고, VMWare가 일본을 장악 했던 떄이죠. 

VMWare의 3.5를 쓰다가 VMWare 4.0부터 많은 부분이 안정화 되었고, 

이 VMWare를 이용한 인프라 관리가 관건이었습니다. 

Xen도 이 때 많이 커지는 듯 하였으나, 어느 정도 중대규모 및 상업용은 VMWare가, 

초 대규모 또는 무상은 Xen이 점령하고 그 밖에 virtualserver, hyper-v, kvm등등 많은 가상화 솔루션들이 있었죠.. 그리고 2011년 정도 되어서 openstack과 cloudstack을 기반으로 오픈소스 진영이 엄청나게 전쟁중이었구요..

VMWare같은 가상화 솔루션은 하나의 머신에 VM을 쓰다가 

vMotion이란 것을 이용해서 가동 중에 여기저기 머신을 오다닐 수 있는 기능을 가지고 있구요, 

그러다 보면 local IP를 바꾸기 일상이죠. 

300대의 물리머신에 대당 10개의 가상머신이 있다면 일일이 동일한 IP로 옮겨다니기 어렵거든요..  

가상 IP를 마구잡이로 넣고 나중에 글로벌IP를 Routing으로 매핑하거나 NAT를 많이 쓰기도 했구요.. 

이 즈음에 Azure 클라우드 서비스가 처음 선보였는데, 

이 때의 Azure에선 고정IP를 사용할 수가 없는 사양이었습니다. 

서버를 리부팅하면 global IP가 바뀌니 도메인만으로 서비스해라.. 

였는데, 그당시엔 그게 불가능한 서비스가 더 많았죠..

그 동안의 인프라 관리 툴에서는 IP가 거의 키가 되었는데, 

여기저기 옮겨다니면서 IP가 마구 바뀌고, 

서버에는 Loccal IP만 탑재되고 글로벌 IP가 바뀌는 바람에

대부분의 인프라 관리 솔루션을 도입하면

바뀌는 IP때문에 문제가 많았습니다. 

게다가 하나의 세그먼트에 하나의 관리툴.. 처럼 들어가다보니

엄청나게 많은 관리툴을 로그인하기도 했죠.. 

vCenter를 살 수 있는 기업이 많지 않았거든요..

이 떄 제가 만든 이 giip라는 인프라 관리 엔진은 2007년에 

고객 인프라를 운영하면서 관리를 편하게 하려고 만들었는데요.. 

VM이나 물리머신, 아니면 회사에 있는 개발 머신까지 

한 화면에서 관리를 하고 소스 동시 배포, OS업데이트 등의

다양한 제어를 했죠. 

이 때만해도 VM관리 전용 솔루션도 거의 없었고, 

있다해도 VM전용이라 물리 머신은 따로 관리하고, 

멀리 떨어진 오피스의 머신을 관리할 수도 없고, 

소스 배포 같은것도 어려웠던 떄였죠.. 

CI/CD란 개념이 거의 2010년 이후에 많은 곳에서 쓰기 시작했거든요.. 

서버에 가벼운 스크립트 베이스의 Agent를 설치하고 

giip서버에 지속적으로 자신의 로컬 IP와 글로벌 IP를 업데이트를 해서

이게 VM인지 물리서버인지, VM이면 어떤 물리서버에 있는지, 

어떤 경로로 찾아 들어가는지를 알기 쉽게 해주고, 

역으로 IP를 몰라도 서버의 고유번호만 알고 있으면

어디에 있는 명령을 내릴 수 있는 획기적인 서비스였죠..

게다가 VM을 생성해주고 역할을 지정하면

그에 맞는 스크립트를 자동으로 받아서 필요한 설치를 혼자 다 해주죠.. 

수백대를 동시에 업데이트하거나 설정해줄 수 있구요.. 

서버가 고장나면 새로운 물리서버나 VM으로 대체해도 

동일 agent의 번호만 들어가면 동일 서버처럼 관리해주죠.. 

방화벽이 막혀있어도 

TCP hole punching이란 개념으로 

해커는 못들어오지만 giip는 외부에서 제어가 되는

무시무시한 툴이었습니다. 

실제로 AWS에서 설정 다하고 iptable에 자기 아이피 넣는거 잊어먹고

전부 닫아버린 뒤에 연결이 안되는 고객이 있었는데, 

그 떄 당시의 aws에서는 그런 유저 실수는 새로 VM만들어라.. 라고 했었고, 

다행히도 giip agent는 설치를 해두었드라구요..

그래서 다 막혀있었지만 iptable을 풀어서 열어줬지요..

이런 엄청난 툴을.. 

알아주는 사람 없이 15년이 흘렀구요.. 

제가 관리중인 인프라 에서는 여전히 giip를 사용하고 있었죠.

예전에 만들어서 그런지 

프론트 웹이 Classic ASP라고 Active Server Page라는 2005년에 MS의 공식 서포트가 종료한

언어를 쓰고 있었죠. 

그래서 이걸 제안한 적도 몇 번 있었는데, 

한국 기업은 하나같이 자바로 만들지 않으면 안된다는 둥 

천대를 받았습니다. 

일본에서는 어떤 언어든 자기네들에게 맞으면 써줬는데..

다행히도

Azure의 App Service가 Serverless로 아직도 올릴 수가 있어서

그래서 계속 쓰고 있는데요.. 

원래부터가 SQL Server에 모든 부하를 주는 서비스다보니

단순히 HTML만으로도 ajax로 통신하는걸로도 서버 관리가 가능했거든요.. 

여기에 UiPath라는 RPA툴이 생기면서 

UiPath용 Agent를 만들어 UiPath Orchestrator라는 천만원이 넘는 중앙관리 솔루션을 

구입하지 않더라도 giip가 중앙에서 수천대의 UiPath에이전트가 깔린 PC를 관리할 수도 있었죠.. 

이렇게 잘 쓰던 어느날.. 

Slack workflow를 쓰다보니 이거 SQL Server랑 연결만 하면 slack으로 컨트롤 되는거 아냐?

하고 고민을 했습니다. 

그래서 chatgpt에게 물었죠.. 

SQL Server를 연결하는 API서버를 Azure서비스로 가장 쉽게 구현하는 방법을 알려줘!

그랬더니 Azure Function App 과 Azure Logic App을 알려주더랍니다. 

그럼 그 둘다 구현 방법과 하루 10만 리퀘스트당 가격을 비교해줘.. 

라고 하니 Function App이 Logic App에 비해 1/10가량 비용이 적다고 합니다. 

너무 차이가 많이 나니까

그냥 Function App으로 하자.. 

그리고 chatgpt가 Python으로 Function App 샘플을 줘서 

그걸로 만들었습니다. 

그런데.. Linux OS에 Python으로 하니 pyodbc가 설치가 안되네요.. ..

찾아보니 Windows OS로 올리거나 비싼 인스턴스로 하거나 Docker로 해야 한다고 합니다. 

다 귀찮아서 그냥 Windows OS로 올리면서 보니까.. 

윈도면 Powershell이 더 편하잖아!

하고 Python을 버리고 Powershell core를 선택해버렸습니다. 

윈도우즈 인프라 관리할 때 powershell로 db연결등을 많이 해봐서 

손에 익숙하거든요..

그리고 시작하려니까 azure에서 기본 앱 소스를 주네요.. 

그걸 복사해서 chatgpt에 붙여넣고 

이 소스를 기반으로 Function app에서 사용 가능한 SQL Server SP를 호출하는 API소스를 만들어줘!

라고 하니 뚝딱 만들어 줬습니다. 

그걸로 function app에 올리고 PostMan으로 테스트하니 성공!

그럼 slack에 붙여야지.. 하고 chatgpt의 도움을 받아서 

Slack app 을 추가 했죠. 

이건 URL과 슬래시커맨드만 설정하면 되니 너무 쉬웠구요.. 

테스트를 하니 슬랙에서는 그냥 안내보내주네요.. 

그래서 slack의 slash command에 맞게 아웃풋을 만들어달라니까

json으로 잘 만들어줬습니다. 

이걸로 API서버는 끝.. 

API를 만들어야 하는데, 

API의 정의를 하나하나 스크립트에서 만드는건 귀찮아서 

SP의 이름중 어간만 따서 api명으로 만들고 

나머지 옵션들은 그대로 넣게 했습니다. 

SP의 가장 큰 장점이 

변수로 받은 데이터는 모두 텍스트로 인지하기 때문에 

Sp_exec같은 시스템 SP만 아니면

SQL 인젝션 자체가 불가능 하죠.. 

SQL서버 사용하시는 분들은 참고하시기 바랍니다. 

이렇게 해놓고 보니 help를 만들어 command리스트를 만들어야 하는데.. 

하고 생각해보니.. 

내가 가진 SP 명을 command명에 맞는 룰로 잘라내고 

파라미터들을 자동으로 뒤에 붙여서 리스트만드는 쿼리만으로 

그럴싸하게 보여줬습니다. 

이걸 조금 수정도 하고 설명도 달고 해야 해서 

자동으로 테이블에 넣는 커맨드를 만들고, 

설명도 넣는 관리자 커맨드를 만들었습니다. 

그리고  giip의 access token 및 서버에서 사용하는 Secret Key를 웹콘솔에서 받아서 넣으면

내 어카운트로 할 수 있는 권한 획득 완료.. 

그리고 커맨드를 실행 했습니다. 

기본 커맨드들, 헬프 커맨드랑

내 정보도 잘 보이고,

가동중인 giip내의 머신에 등록된 정보들도 잘 보이네요.. 

등록된 소스도 잘 보이구요.. 

아직 소스를 slack에서 수정할 수 있는지 모르기 때문에, 

소스는 보기까지만 하는걸로 하고.. 

이렇게 API서버를 구현해서 

표준화만 잘 하면 API서버 만들때 필요한 고생을 전혀 안해도 되게 되어 버렸습니다. 

몇 년 전까지만해도 

API서버를 표준화 하는데 들여야되는 시간과 비용을 생각하면 

아찔했는데 말이죠.. 

DB만 잘하면 개발을 잘 몰라도

API서버를 만들어 slack을 UI로 해서 서비스를 만들 수도 있다!

고 말하고 싶지만, 

역시 저 짧은 한 페이지의 API서버를 구현하는데도

지식이 있는것과 없는 것의 차이는 좀 크긴 하더랍니다. 

(스마트 하게 표시하는 데에는 powershell을 조정하는 시간이 좀 걸림..)

그래도 이젠

SP를 만들면 자동으로 API가 되어버리고, 

간단하게 API매뉴얼을 추가할 수 있게 되어서

API추가나 사양 변경이 그냥 

쿼리 변경 정도로 끝나게 되었습니다. 

이제 슬랙 챗으로 

자유롭게 백업이나 서버 재기동을 하고, 

서버내 필요한 정보를 

채팅만으로 가져올 수 있는 환경을 만들었습니다. 

나중에 LLM을 어떻게 도입할지도 좀 고민해봐죠.. 

리스크가 있는 작업들이다보니 

바로 LLM에게 시키는게 아니라 

작업에 맞는 스크립트를 만들어달라고 하는 식으로 현재 쓰고는 있지만, 

연결되어 있진 않고 채팅하다가 제일 적절한 것을 

수동으로 골라서 giip의 작업 큐에 넣고 있지요.. 

이렇게 여러대의 서버를 채팅으로 관리하기 시작했습니다. 

앞으로 문제가 생기면 대처 방법까지

채팅으로 자동으로 제안해주는 서비스를 

만들 날을 기대하면서.. 

여러분도 참고가 되셨으면 합니다. 

giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/