はじめに
この記事はNikkei Advent Calendar 2021の22日目の記事です。
こんにちは！API・バックエンド/SREチームの千葉です。 本記事ではSREチームが開発・運用しているアプリケーション基盤「Vessel」について紹介したいと思います。
Vessel開発に至った経緯
弊社では、各開発チームが自身の受け持っているサービスのアプリケーションから基盤までを管理していることが多いです。 長らくこのような体制でサービス開発を進めてきましたが、以下のような課題が生まれました。
- 基盤の構築・運用に時間を割かれて、アプリケーション開発に集中できない
- 報道機関という特性上、サービスには高い信頼性が求められるため、基盤の構築・運用コストが高くなる
そこでSREチームは以下に示す理由から、課題解決に対して共通のアプリケーション基盤が有効であると考えました。
基盤の構築・運用に時間を割かれて、アプリケーション開発に集中できない
⇒ サービス開発・運用における共通の部分をSREが管理することで、開発者はアプリケーションの開発に注力できる
報道機関という特性上、サービスには高い信頼性が求められるため、基盤の構築・運用コストが高くなる
⇒ SREが共通基盤側で信頼性を作り込むことで、サービス毎に作り込む場合に比べてコストを下げつつも高い信頼性を実現する
また上記以外にも、共通基盤によって実現される統一的な運用・監視によって、SREチーム側が各サービスの状態を把握しやすくなるといったメリットも存在します。
What's Vessel?
ここからは、Vesselの具体的なアーキテクチャについて説明したいと思います。 ここでは、以下に示すアーキテクチャ図をベースに説明していきたいと思います。
アプリケーション実行基盤
アプリケーション実行基盤としてはGoogle Kubernetes Engine(以下、GKE) + Anthosという構成をとっています。
具体的には、各サービスのアプリケーションが実行される2つのサービスクラスター(service, canary)とそのクラスター群を管理するためのコンフィグクラスター(config)の計3台で構成されています。
また、複数クラスター構成を実現するためにAnthosの機能であるMulti Cluster Ingress(以下、MCI)を導入しています。
さらに、GKEクラスター上でサービスメッシュを実現するためにAnthos Service Mesh(以下、ASM)も導入しています。
まず、Kubernetes(GKE)を採用した理由としては、マニフェストを用いた責任分離が可能である点にあります。
つまり、
- 各サービスに共通の部分(Kubernetes Clusterやその下回り)はSREが管理
- サービス固有のインフラ(Deployment, Service, ...)は各チームが管理
と管理対象を分離することで、各チームはより自身のサービスにフォーカスすることが可能になります。
次に、Anthosを採用した理由としては信頼性の向上が挙げられます。 以降はこちらについて深堀りしていきたいと思います。
まず、MCIを利用することで先述の通りマルチクラスター構成を取ることができるようになります。
これによりクラスターレベルでの障害に対応できるようになりました。
例えば、serviceクラスターで障害が起きた場合、前段にいるGoogle Cloud Load Balancing(以下、GCLB)のヘルスチェックによって自動的にバックエンドから除外されます。
これにより迅速に障害影響を局所化することが可能になります。
またマルチクラスター構成は、基盤アップグレード作業の失敗時にユーザへ悪影響を与えてしまうリスクを低減します。 SREチームが基盤のアップグレードを実行する場合、
canaryクラスターをGCLBのバックエンドから切り離し、当該クラスターへユーザトラフィックが完全に流れない状態を実現- 当該クラスターのControl Plane及びWorker Node(ASMの場合、Data Plane)をアップグレード
- 当該クラスターの正常性を確認後、再度GCLBのバックエンドに追加
serviceクラスターのアップグレード作業も同様の手順で行います。
このように片方ずつクラスターをアップグレードできる環境が、ユーザに悪影響を与えてしまうリスクを低減し基盤運用者の心理的安全性を向上させます。
さらに、ASMを導入することでアプリケーションの柔軟なリリースが可能になります。 VesselではアプリケーションのBlue/Greenデプロイをサポートしています。 具体的には、Blue/Greenの面をDeploymentとして用意して、どの面にトラフィックを流すかという制御をASM(Istio)のCustom Resourceを用いて実現しています。 これにより、もし新しくデプロイしたアプリケーションに問題があった場合でも瞬時にロールバックしユーザへの影響を局所化できます。
今回記載した一部内容は、以前開催されたOpen Cloud Summit 2021でも紹介しています。 もしよろしければ、発表資料や動画もご確認いただけると幸いです。
CI/CD
CI/CD部分については、以下に示す概要図をベースに説明します。
まず、CD部分はArgoCDで実現しています。 これにより、各アプリケーションのコンテナイメージとマニフェストが所定の場所（それぞれ、Google Container Registry、GitHub repository）にあれば、あとは自動的に各クラスターへアプリケーションがデプロイされる環境を実現しています。
このデプロイの自動化以外にも、GitHub上で操作が完結するというGitOpsの特性も信頼性の向上に寄与しています。 例えば、先程述べたBlue/Greenデプロイのロールバック時です。 Blue/Greenの面を切り替える操作がGitHub上のPRとして実現されているので、ロールバックする場合はそのPRのマージコミットをリバートするだけで完了します。
CIはCircleCIを利用して実現しています。 具体的には、
- SREチームがCircleCIのパッケージングの仕組みであるOrbsを作成し開発者へ提供
- 開発者が自身のサービスのCIへOrbsを組み込む
という形になります。 特にOrbsでは、
- コンテナイメージのビルド・プッシュ
- Kubernetes、ASMのマニフェストの生成
- 生成したマニフェストをマニフェストレポジトリへプッシュ
- Blue/Greenのスワップ
等様々なことを実現しています。
これらの仕組みにより、開発者はアプリケーションの要求リソースやレプリカ数等を指定する最小限のマニフェストを用意するだけで、容易にVessel上へアプリケーションをデプロイできます。
監視基盤
監視基盤はGoogle CloudのOperations Suite + ASMで構成されています。 特にASMを導入することで、
- Cloud Loggingに各アプリケーションのアクセスログを自動収集
- Cloud Monitoringに各アプリケーションのリクエスト数、レイテンシ等を自動収集
- ASMダッシュボードでREDメトリクス等を自動的に可視化
も実現しています。
監視部分においてもただ基盤を用意するだけではなく、開発者が簡単に自身のサービスの監視を始められる仕組みを用意しています。 具体的には、SREチーム側でダッシュボードとアラートのプリセットを用意しておくことで、アプリケーションをデプロイしたその日から最低限の監視が実現されるようになっています。 ダッシュボードとしては以下のようなものを用意しています。
終わりに
現在Vessel上では日経電子版のWebサイトが稼働しており、今後も新しいサービスへこの基盤を導入する予定です。 SREチームは今後もVesselの改善を進めていくことで、サービスの信頼性を担保しつつ開発のアジリティを向上させて行きたいと考えています。 現状のVesselの改善方針としては以下が挙げられます。
- 低運用コストかつ高い信頼性を持つアプリケーション実行基盤の実現
- e.g. ASMのGoogle-managed Control/Data Plane, GKE Autopilotの導入
- 詳しくはSREチーム山崎の記事をご確認下さい
- Observabilityの向上
- e.g. GKE Workload Metricsの導入
- 詳しくはSREチーム清水の記事をご確認下さい
SREチームではVessel以外にも、障害管理ツールの開発や共通Terraform Moduleの整備等様々な活動を行っております。 もしテクノロジーでメディアを作っていく仕事に興味のある方は、ぜひJOBSページからご連絡下さい！
明日は杉本さんによる「日経SREの取り組み2021年版」です。楽しみですね！
