안녕하세요. Azure Cloud Solution Architect의 아키야마입니다. 이번에는 마모 루 비즈니스 에서 k8s로 마이그레이션한 이야기를 계속 전해드리겠습니다.
- Vol.1 앱 서비스에서 AKS로의 이전 결정
- 제2권 AKS(k8s) 마이그레이션 준비
- 제가 Vol.3 AKS(k8s) 마이그레이션 <- 本記事
移行をどのように進めたかについて書きます。 まずは移行のスコープの検討です。
移行の進め方
今回の移行では Azure インフラの置き換えが主であり、例えばアプリケーションが動作している Docker コンテナについてはこれまでのものをそのまま k8s 上で動かすことにしました。 (Mamoru Biz では Docker イメージを管理しているのは基本的にアプリケーションエンジニアです。)
これは、できる限りインフラエンジニアがコントロール可能な範囲で移行を進めるための措置です。 (実際には k8s 上で動くようになった後に App Service 向けにカスタマイズしていた Docker コンテナを修正する、ということも追って対応しました。)
移行のスコープ
移行のメインターゲットは App Service ですが、 AKS(k8s) で代替可能な機能は置き換えることを計画していました。 Vol.1 기사 에 쓴 작업 실행 역시 마찬가지입니다.
컨테이너 인스턴스 외에도, Logic App의 HTTP 요청을 이용해 Administrator Web API를 실행하는 작업도 있었습니다. 이 기능들은 개발자가 직접 만들 수 있는 것이 바람직하기 때문에 마이그레이션 대상이 됩니다.
가장 큰 범위를 염두에 두고 실제로 진행할 때 파레토 원칙 을 따랐고, 주요 부분은 첫 번째 릴리스의 범위였습니다. 이 범위는 프로젝트 진행에 따라 미세 조정되었고, 결국 우리가 생각했던 것보다 더 작은 범위로 첫 릴리스를 완성했습니다.
그 결과 마이그레이션 중에는 문제가 없었지만, 문제가 발생했을 때 문제를 최소화하기 위해 소규모 단위로 여러 번 릴리스하는 것이 적절했다고 생각합니다.

Azure 인프라 환경을 구축하세요
환경을 구축할 때, 우리는 이 마이그레이션 프로젝트 이전부터 개발, 스테이징, 프로덕션 세 환경 간 차이를 최소화하기 위해 Terraform을 사용해 왔습니다.
이는 "애플리케이션이 스테이징 환경에서 데이터베이스에 접근할 수 없고(개발 환경에서는 괜찮았음에도 불구하고), 방화벽 구성이 불충분하다"와 같은 문제를 방지하기 위한 조치입니다.
Terraform은 Terraform 의 실행 환경으로 사용됩니다. 전반적으로 만족하며, 한 가지 언급할 점은 Access Control 기능이 유용하다는 것입니다. 마모루 비즈는 Terraform의 숙련도와 인프라 엔지니어의 환경 이해 정도에 따라 'terraform 적용'이 실행될 수 있는 환경을 제한합니다.
DevOps 환경 개발
앞서 인프라 DevOps에 대해 언급했지만, k8s 계층의 DevOps 환경은 이 프로젝트를 통해 유지보수되어야 했습니다.
참고로, App Service는 지원되는 기능을 사용해 컨테이너를 그대로 전환했습니다. 참고: Azure App Service에서 커스텀 컨테이너를 이용한 지속적 배포 이 부분이 잘 처리되어 있어 감사합니다.
k8s 계층에는 GitHub Actions 를 사용했습니다. k8s 매니페스트의 변경 사항을 감지해 AKS에 적용합니다.

우리는 Helm 을 배치에 사용합니다.
DevOps 환경이 출시를 더 쉽게 만들었지만, 이 메커니즘은 App Service 시대의 배포와 비교해 운영과 속도 면에서 여전히 개선이 필요합니다.
결론
지금까지 세 개의 글로 나누어 저희 서비스 Mamoru Biz 를 App Service에서 AKS(k8s)로 이전한 프로젝트를 소개했습니다. 이전 자체는 완료되었지만, 고객에게 더 높은 수준의 '이름 없는 작업 감소' 서비스를 제공하기 위해 작은 개선 작업을 계속할 예정입니다.
마지막으로,
Colorkrew에서는 자신의 서비스 개발과 계약 사업 모두를 경험할 수 있습니다. 저희 회사에 관심이 있으시면 채용 페이지에서 입력해 주세요.
컨테이너 구성 시스템 도입에 관심이 있으시면 아래에서 저희에게 연락해 주세요. 서버리스/컨테이너 구현 지원 |