こんにちは。Azure Cloud Solution Architect の秋山です。
今回の記事では自社サービスで AKS 導入を始めて1年が経ち、どうやってきたか、何が変化したのかについて書きます。
1年前に書いた Azure Kubenetes Service(以下 AKS) 移行の記事は以下です。
AKS クラスターバージョンの更新管理
AKS では最新バージョンから２世代前までのマイナーバージョンをサポート対象としているため、
4-5カ月周期でリリースされるマイナーバージョンをキャッチアップする必要があります。
参考:AKS Kubernetes リリース予定表
Mamoru Biz では AKS クラスターをインプレースアップグレードと呼ばれる手法で更新しています。
システムが利用中のクラスターのバージョンをアップグレードし、ノードを順にアップグレードする方法です。
参考:Azure Kubernetes Service (AKS) クラスターのアップグレード
もう一つ Blue/Green デプロイメントと呼ばれる手法も検討しましたが、利用していません。
下の図のように、現行クラスターに加えて新バージョンのクラスターを用意し、Front Door や Traffic Manager などで切り替える方法です。
インプレースアップグレードのメリットは以下
- (Blue/Green による切り替えに比べて)インプレースでは純粋に k8s のみを理解すれば Azure インフラ構成を理解していなくとも(ほとんどのケースにおいて)よい
- サービスが利用する外部 API にアクセス可能なIPアドレスを登録する必要がある。アウトバウンドのIPアドレスが変わる場合はケアが必要
インプレースアップグレードのデメリットは以下
- Blue/Green では一気にバージョンを変更できるのに比べて、インプレースでは0.1ずつアップグレードが必要
- Blue/Green では切り替えの切り戻しによって元の環境に戻れるが、インプレースではそれができない
(インプレースではこの点については開発/検証/本番の3環境で事前検証することでカバーする)
これらのメリット・デメリットを考慮し、現在はインプレースアップグレードによって更新しています。
開発チームとインフラチームの役割分担
1年で役割分担も徐々に変化しました。
1年前 AKS 移行を行ったときはインフラメンバが主導した背景から、インフラメンバが Azure やもちろん k8s のマニフェストを管理しており、開発者はアプリケーションコードを変更するまでが主な役割でした。
図にすると以下のとおりです。
開発者の中で k8s のキャッチアップが進んだことで、今は機能要求に対しては開発者が自分でマニフェストを書くようになりました。
インフラメンバはクラスターを安定稼働させるための施策や開発者の Pull Reqeuest のレビューなど、負担はかなり減りました。
図にすると以下のとおりです。
今後の展望
先日の Microsoft Build で Azure Container Apps がGA しました。
参考: Azure Container Apps | Microsoft Azure
AKS のクラスター管理は k8s を深く理解し活用する上ではよいのですが、人的コストが比較的かかる業務です。
マイクロサービスを包括的に管理でき、かつ管理コストを削減できるソリューションとして Azure Container Apps のサービス導入について検討しています。
最後に
Mamoru Biz は順調にユーザベースを伸ばしており、今後もインフラの安定性と新機能を提供可能な拡張性が必要です。
最近では Mamoru Biz に限らず自社サービスの開発が徐々に活発化している背景があります。
そこでインフラメンバが個人ごとにバラバラに運用する体制から、一貫性を持って自社サービス全般を支えるインフラチームとして活動し始めました。
まだメンバ自体は他の業務と兼務する体制ですが、組織的にも少しずつ変化しています。
Colorkrew では自社サービスの開発と受託ビジネスの両方を経験できる環境があります。
もし弊社にご興味がある方がいらっしゃいましたら、 採用ページ からエントリーしてみてください。
また、コンテナ構成のシステムの導入支援についてご興味がある方がある方は以下からお問い合わせください。
サーバーレス/コンテナ導入支援 | くらまね
