기본 콘텐츠로 건너뛰기

AIX의 대규모 오라클데이터를 x86으로 마이그레이션 하면서 있었던 일...

영상 버전 :  https://youtu.be/KtRKb2Py5xs 아무 생각없이 쉽게 생각해버린 20 년간 축적된 AIX위의 ORACLE 데이터 이전 작업..  AIX가 서비스연한이 다되어 신규 구매를 해야만 하는 상황이다. 신규 구매 18억 + 연간 6억원의 유지 비용. 5년 사용기준으로 연간 약 10억원의 비용이 드는 것을 x86으로 교체함으로 신규 구매비용 5천만원(2대 이중화)으로 퉁치고 오라클 라이선스도 44Core -> 16 Core로 줄이는 것이 이번 프로젝트의 목표이다. 별 준비 없이 오라클이니까 라는 생각만으로 너무 자체 기능을 믿고 진행 한 것이 문제 였다.  서비스 정지 허용 시간은 교섭에 교섭을 해서 단 7시간..  Full backup만으로 40시간이 걸린다. 게다가 센터가 클라우드 센터 내에 있는 물리 서버라 백업 장비 반입 불가, 백업 영역이 500GB도 채 남지 않은 곳에서 NAS 이용 불가, 1Gbps 네트워크에서 알아서 하랜다. 프로젝트를 받고 나서 이런 상황이었다는 사실을 뒤늦게 알았다.. 당연히 이런거 다 지원해주는 곳인줄 알았는데.. ㅠㅡㅠ 나중에 안 얘기로는 SI업체 견적으론 30억이었다고 한다.  이전이 결정되자마자 DBA는 사표를 던지고.. 대타가 없어 내가 들어와서 간단한 인수인계만으로 준비를 시작.. 서버 선택에서부터 이전준비, 이전작업까지 모두 나 혼자 하게 되어버렸는데, 그냥 그 동안의 경험상 문제 없겠지 하고 개시.. 사전에 이건 미션임파서블이기 때문에 일부 데이터의 누락이 발생하거나 하면 수동처리하는 걸로 합의 했다.  병렬 export & import용 스크립트를 만들어서 충분히 테스트 해봤다. 별 문제없이 계산 상으로 7시간정도에 맞출 수 있었다. 이전 당일... 서비스 정지후 복사 작업 진행.. 사전에 변경되지 않을거라 생각되는 2800여개 테이블을 미리 복사해두고 남은 1500여개의 테이블을 복사하는 시간만 40시간인 것이다.  병렬 export 및 import를 스크립트화 하여 10개

일본의 디지털청은 모르겠지만 디지털화의 현주소

요즘은 한국과 일본과의 관계가 안좋아지고 코로나 때문에 왕래도 거의 사라져 버렸지만,  경제라는 것은 흐름이 있기 때문에  알아두면 참고가 되지 않을까 싶습니다.  공공기관의 인터넷화는 한국이 일본보다 확실히 앞서 있습니다.  그리고 연간 해외 수출액도 작년도 기준으로  일본이 800조정도에 한국이 600조 정도로 많이 따라 잡았습니다.  하지만 RPA가 언급되기 이전 부터 자동화의 관점으로 보면 일본의 경우가 많이 진전되어 있었습니다.  RPA이전부터 자동화에 대한 니즈 및 자동화 솔루션이 많이 나와 있었구요..  이제와서 RPA라고 해서 붐이 다시 일어나는 것보다,  RPA 툴이 진화되면서 자동화의 영역이 더 넓어졌기 때문에  더욱 급속도로 확대 되고 있지요.  그런 반면 한국에선 아직도 눈치보기로  어디 대기업이 도입되기를 기대하면서  시범적으로 도입하고 그걸 기사화 하는 정도가 현실 입니다.  치열하게 효율화에 목숨을 걸고 투자를 하는 일본과 잠깐 맹렬하게 이슈화 되었다가 사라지는 것이 반복되는 한국.. 많은 시도를 할 수 있는 테스트베드가 되는 것은 좋으나,  결국 테스트 후에 세계 시장에서 돈을 버는 것은  한국에서 테스트베드를 경험한 사람들이 참여한 해외 기업이 되네요.  이 좋은 테스트베드의 경험을 사업으로 이끌고 일본이나  다른 해외에 진출하는 IT기업이 있다면 큰 성공을 하지 않을까 합니다.  하지만,  예전에도 언급한 경험담이지만,  한국에선 해외 진출을 위해 도와주는 투자자 또는 기업중에 IT기술 자체에 점수를 매기는 경우가 없지요.  그렇기 때문에 솔루션 회사 혼자 해외에서 맨땅에 헤딩하고 우연히 살아남아도 글로벌 기업에 먹히는 정도가 다이지 않나 싶습니다.  일본은 한국이나 해외의 국가 디지털 사업을 벤치마킹하여  2025년까지 개인번호(주민등록번호 같은것)만 있으면 많은 것들이 해결되는 시스템으로 만든다고 하고,  많은 기업들이 연동을 하고 있습니다.  이 얘기를 하다가 재미있는 얘기를 들었는데요... 한국은 여러 은행의 계좌 통합관

개인적으로 경험한 헤드헌터라는 직업에 대해서...

오랜만에 들어와서 보니 그렇게 중요하지 않은 내용으로 갑론을박이 한창인 것을 보고 놀랐다.  내가 한국 사람들의 정서와는 많이 달라서 그런 것일 수도 있지만, 많은 사람들이 자기의 입장에 대해서 잘못 알고 있는 것 같아서 가장 중요한 경제활동의 근본 부터 말하고자 한다.  대부분의 문제가 상대방을 이해하지 못하는 상황에서  자기의 불편함 만을 강조하면서 초래되는 이야기인데,  내가 MS Office가 있지만 복잡한 업무처리를 보다 수월하게 하기 위해서 SI 또는 클라우드 서비스에 돈을 지불하고 편리한 시스템을 이용하게 된다.  돈을 내는 나의 입장에서 SIer나 클라우드 서비스 업체에서 나에게 불만을 얘기하면 난 바로 다른 곳을 찾게 된다.  내가 돈을 내는데 왜 불만을 들어야 하지? 게다가 나의 시간을 절약해주기 때문에 서비스를 이용하지 않나? 얼마 전에 올라왔던 이야기를 축약하자면 헤드헌터라는 사람이 자신의 고객이 연락 없다고 매너를 거론하면서 불만을 늘어 놓았다.  내가 소비자라면 그런 불만 많은 헤드헌터를 이용할 이유가 없다.  내가 바쁘기 때문에 챙기지 못하는 만큼 헤드헌터에게 맡기는 것 아닌가? 외국계 헤드헌터 I사의 경험담을 적어본다. I사의 헤드헌터는 회사 담당자와 많은 대화를 하여 어떤 사람을 찾고자 하는지에 대해 아주 구체적으로 찾아낸다.  그리고 개인들을 직접 만나보고 개인의 이상적인 회사에 대해서 오랜 시간을 들여 이야기를 했다. 두어시간 이야기 하고 나서 개인에게 가장 적합해보이는 회사를 10 개정도 추려 왔다.  그리고 이 회사가 왜 이 개인에게 적합한지 자신의 의견을 회사별로 이야기를 했다.  그리고나서 개인이 지원하고 싶다고 생각한 회사가 세 개정도 될 때까지 계속 10개씩 회사를 추려오면서 여러가지 이야기를 해줬다.  결국 세 개의 회사를 지원하게 되었다.  면접 전에도 어떤 사람을 원하기 때문에  어떠한 사람이 되겠다는 포부를 이야기 하라는 등의  회사별 면접의 포인트도 알려주었다.  그리고 모든 지원에 이 담당자와 함께 면접을

SQL Server 의 모니터링

SSMS(Sql Server Management Service)툴에서 제공하는 간단한 모니터로 대부분의 성능 이슈를 잡아낼 수 있다.  https://serverfault.com/questions/578533/ms-sql-server-getting-overloading-with-suspended-queries-mostly-reads-any-wa 일단 정리 용... giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

AWS 관련 정보 정리 링크

AWS는 IOPS가 굉장히 민감하기 때문에  자기의 Instance가 지원되는 IOPS인지를 체크해야 한다.  Instance의 IO Network Bandwidth와 EBS의 Throughput 과 IOPS 중 하나라도 느리면 그 곳에서 병목이 발생한다.  EBS Specification:  https://aws.amazon.com/jp/ebs/volume-types/   EBS Volume Type :  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html 일단 정리용으로 대충 올려 놓음.. giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

누구를 위하여 종을 울리나

제목이 조금 거창하지만... 스타트업에게 이야기 할 때 많이 하는 얘기가 있습니다. 요즘은 IT서비스를 플랫폼화 하여 성장하는 기업이 주류 입니다. 플랫폼은 다수의 공급자와 다수의 수요자를 연결하는데 의미가 있습니다. 거기서 많은 시행착오를 일으키기도 하는데요.. 선택의 기로에 설 때가 많습니다. 선택이란 양쪽이 좋은 것 보다 선택 받지 못한 다른 한 쪽이 손해 또는 이득이 적어지는 경우가 대부분 입니다. 이 경우 가장 중요한 것은 누가 나에게 이득을 주느냐 입니다. 설계한 서비스를 이용함으로서 한쪽은 재화를 지불 하고 다른 한 쪽은 재화를 얻는 경우가 대부분 일 것입니다. 재화를 지불하는 곳이 재화에 상응하는 편리함을 제공하지 않는다면  이용자가 줄어들어 아무리 많은 공급자를 가지고 있다 하더라도 서비스는 지속되기 어렵습니다. 이걸 가장 잘 알았던 기업이 애플이었죠. 아무리 개발자가 불평이 많아도  이용자가 서비스 이용이 편리하여 돈을 써주기 때문에 구글의 플레이 스토어 보다도  애플의 앱스토에 충실 고객이 늘어납니다. 사이먼씨의 이야기를 빌리자면 마틴 루터 킹 같은 종교 지도자나 애플의 유저를 끌어들이는 정책은 일치하고 돈을 지불하는 것에 안심감 및 프라이드 마저 느낄 수 있도록 해주었기 때문에 일방적으로 개발자에 불친절한 앱 관리 시스템에 개발자는 애플을 욕하면서도 앱스토어 출시를 하게 되는 것이지요. 인재파견 및 소개 회사도 마찬가지 입니다. 다수의 수요자는 기업이고, 다수의 공급자는 취업 희망 개인입니다. 물론 양쪽을 편하게 해주면 좋겠지만, 경제 구조상 수익률을 위해 동일 시간에 최대한 노력을 해야하기 때문에 한 쪽은 신경을 덜 쓰게 됩니다. 이 경우 취업 희망자에게 아무리 신경을 쓴다 하더라도  기업이 불편하면 안쓰게 됩니다. 그럼 돈을 지불할 기업이 사라지니 결국 이 플랫폼은 돈이 돌지 않아 망하게 될 겁니다. 그렇다고 구직자를 대충 대하라는 것이 아닙니다, 최대한의 서비스를 하되, 시간이 부족하다면, 보다 기업의 채용 담당자의 채용까지 걸리는

mongodb에서 mysql로 간단하게 데이터 임포트 및 익스포트

누군가 요청해서 재미삼아 만들었음.. mongodb를 mysql에서 불러들이는 방법은 몇 가지가 있는데요..  1. mongodb에 mysql 모듈을 설치해서 mysql에서 호출하는 방법..   -> 설정이 많이 필요해서 귀찮음 2. mongodb에 mysql 5.7이후라면 json import를 이용해서 json으로 집어넣는 방식   -> mongodump를 이용해서 json 파일로 넣고 json_import를 이용해서 테이블에 넣으면 되기 때문에 간단한 명령으로 쉽게 정리 됨.    단점은 KVS(Key Value Store)로 저장되기 때문에 쿼리가 살짝 귀찮아짐.. 기존 쿼리를 사용할 수 없다.  SELECT doc->>"$.name" AS name FROM test.my_restaurants WHERE doc->>"$.cuisine" = "Italian"    요런 느낌으로 쿼리를 짜야 함. 3. mongodump로 json으로 떨군 뒤에 jq로 읽어서 쉘로 필드를 뽑은 뒤에 mysql커맨드로 insert처리를 함.       #!/bin/bash      # Useful date text     TodayYYYYMMDDHH24MISS= `date '+%Y%m%d%H%M%S'`     TodayYYYYMMDD= `date '+%Y%m%d'`     TomorrowYYYYMMDD= `date +%Y%m%d --date '1 day'`     YesterdayYYYYMMDD= `date +%Y%m%d --date '1 day ago'`     NextMonthYYYYMMDD= `date +%Y%m%d --date '1 month'`     PrevMonthYYYYMMDD= `date +%Y%m%d --date '1 month ago'`     delete sqldump.sql     j