IT 쟁이로 살아가기 - 너무 어렵..

꿈은, 꼭 이루어지기를 기대 한다기 보다는 존재만으로도 힘이 되고 삶의 동기가 되곤 한다. 목표는, 현실적으로 이루고자 하는 과제이다. Dream 과 Goal 정도? 살다보면 요즘처럼 목표가 희미해지고, 그럴때가 있다. 솔직한 말로.. 꿈은.. 희미해진지 오래되었다. 현실을 마주하며 살다보면 꿈보다는 목표가 중요하고, 목표의 유통기한 마저도 점점 짧아진다. 어는 회사에서 brand new start 를 한다고 치면, 나의 경우 이렇게 목표를 잡고는 한다. "일단 1년 버티고(퇴직금은 받아야 하니), 잘되면 1년 연장, 더 잘되면 2년 연장, 그 이후는..? 몰라" --> 이러면 프리 뛰는거랑 뭔 차이가 있지? ㅋ 요새는 이마저도 잘 안되지만.. 목표가 없어지면.. 정말 갈피를 못잡을 텐데 큰일이로다

케이스) 일반적인 웹애플리케이션인데 K8S에서 서비스 한다고 가정하자. 그런데 이 K8S가 자주 업그레이드를 해야 한다고 하면? 훅 건너뛰어 지금은 22년 9월 본 포스팅을 올릴 때만해도 운영서비스에서 업그레이드를 한번도 안해본 때라 고민이 많았던 상태였고 지금은 이미 업그레이드를 몇 번 해본 상태라 조금 다른 시각으로 K8S 업그레이드에 대해 언급할 수 있을 것 같다. - 업그레이드 자체 - 클러스터 롤링 업그레이드라 다수의 Replica로 구성된 WEB/WAS는 사실상 영향이 없었다. - 문제점 - Pod -> Legacy 연동, 특히 방화벽 문제가 어렵다. - OpenShift의 경우, Pod -> Legacy 네트워크 연계시 EgressIP를 통해 Source NAT를 한다. 운영기의 경우 Egr..

최근 업무도 그렇고 후배를 통해 비슷한 자문 요청이 오기도 하는데 - 용량산정을 어떻게 해야 하는지에 대한 내용이다. 과거, 대략 한 20년 전부터 10년 전까지의 용량산정은 하드웨어의 성능 측정치에 의존했던걸로 기억한다. 예를 들어, 사업팀에서 설계한 서비스는 대략 어느정도의 동시사용자, TPS를 수용해야 한다는 목표가 있고 설계팀은 이를 토대로 시스템의 용량(capacity)를 산정해야 한다 그 시절의 OLTP에 필요한 SW는 선택의 폭이 딱 다음 정도인데, - AIX, HP-UX, Solaris 등 Unix 서버 - Tuxedo, Tmax 등의 TP, 아니면 J2EE 기반의 WAS - WebLogic, Jeus, WebSphere, JRun, OC4J 정도 - Presentation Layer, 또..

가끔 여러가지 상상을 하곤 하는데, 그 중 하나는 내가 만약 강단이나 교직에 선다면 후학들에게 어떤 가르침을 주는 것이 가장 좋을지를 생각해 보곤 본다. 학문은 절대적인 진리가 아님을 염두해야 한다. 살다보면 바뀔 수도 있다. 언제가 될지는 모르지만. 기술은 빨리 변하고 발전의 개념도 있지만 대체의 개념도 있기 때문에 평생 적용될 것이라는 고집은 버려야 한다. 지금 배우는 것이 과연 당신들이 사회에 나가서 써먹을 수 있는 것들인지 의심해야 한다. 하지만, 그래도 배우고 기억해두면 도움이 된다는 것도 알아야 한다. 어쩌면 이 배움의 결과는 지식이라는 것이 아니라 그 지식을 얻고자 수학했던 과정일지도 모른다. 우리 삶에 있어서 인간의 지식이라는게.. 절대적 불변의 진리라는게 있을까 싶기도 하다.

난 주로 openshift를 사용하기 때문에 oc 클라이언트로 cli 를 날린다고 가정한다. 하지만 kubectl을 써도 사실은 동일하니 큰 차이는 없음 yaml에서 데이터 타입 별 추출 - 일반 값 예를 들어 오브젝트가 아래와 같은 yaml 구조를 보인다고 가정하자. - OpenShift의 Project(namespace) 여기서 metadata.name 은 일반 값이다. 즉 key:value 가 1:1 맵핑이다. apiVersion: project.openshift.io/v1 kind: Project metadata: annotations: openshift.io/display-name: XXXX openshift.io/requester: system:admin openshift.io.sa.scc.m..

지난 주 토요일 오전에 GCP Professional Google Cloud Architect 시험을 봤다. 코로나 시대 비대면의 흐름에 발맞춰 OnLine 시험을 치르면서.. 그동안 면접, 입사시험 등등 몇번을 온라인으로 했더니 이젠 이마저도 익숙해지고 생각보다 집에서 시험보고 면접보는게 장점이 있다는 생각이 든다. 물론 인터넷이 느리지 않고, 이를 위한 격리된 공간이 있을 경우의 얘기이고 만약 우리애가 갓난쟁이이거나 완전 꼬맹이였다면 좀 힘들었을 것 같다는 생각이 들기도 한다. 시험은 생각보다 잘 봤는데.. 준비하면서 느낀게 나이 탓, 핑계 대면서 암기가 잘 안된다고 하는 것도 이젠 좀 진부하고 그냥 새로운거라서, 내게 익숙치 않은거라 그런갑다 싶으면서도 머리에 잘 안들어오고 공부라는건 학창시절에도 ..

문뜩 다시 글을 남겨야 겠다는 생각이 들어 블로그에 들어와 봤다. 얼마전 아는 업체 임원분 통해 그분 회사에서 출간 예정인 기술서적의 서평을 부탁한다고 해서 정말 오~래간만에 업무 메일, 카톡 메시지 글이 아닌 출판용? 글을 썼다. 원래도 필력이 뛰어난 건 아니었지만 그래도 그동안 제안서, 부탁 메일? 등으로 다져진 필력은 좀 되는 편이었는데 그 동안 내가 너무 비굴한 메일만 보낸건지.. 필력이 바닥이 되었더라. 물론 그 이유 때문은 아니지만.. 그 동안 일기를 쓴 것도 아니고 메일, 자료 같은 것들은 클라우드 어딘가에 방구석 어질러 놓은 것처럼 되어 있어서 다시 블로그를 써보기로 했다. 이렇게라도 정리하지 않으면 나중에 아무도 나에 대해 기억하지 못할 것 같아서 ㅎㅎ;; 다시 시작하는 주제는 기술 중심..