イベント

JR東日本やみんなの銀行、アサヒグループ、ドコモなどが登壇し、コンテナの活用事例を紹介

「Google Cloud Anthos Day」ユーザー事例セッションレポート

日経電子版:IstioとGitOpsでマイクロサービス基盤を刷新

 技術セッションだが、日本経済新聞の「日経電子版」ついてのセッションも、日本経済新聞社の安田竜氏(デジタル編成局 ソフトウェアエンジニア)により行われた。

 日経電子版では、以前からマイクロサービス構成を採用していた。そこでの課題として、まず「リリースで壊れやすい」ということがあったという。事前環境では動いていたのに本番で壊れた、といったことだ。

 もう1つの課題はマイクロサービスの監視・運用が大変ということで、サービスとチームが分かれて個別にインフラを運用に、監視や運用の手法と品質がバラバラで、サービス横断の監視や調査も困難だったという。

 そこで、SREチームが発足し、新基盤を構築することになった。目的は、シンプルで安全で統一された運用を強制する仕組みによる「信頼性の改善」と、統一された監視と運用による「信頼性の把握」だ。

日本経済新聞社の安田竜氏(デジタル編成局 ソフトウェアエンジニア)
課題1:リリースで壊れやすい
課題2:課題はマイクロサービスの監視・運用が大変
新基盤の目的

 新基盤では、Kubernetes/IstioをGitOpsで運用する。まずリリースで壊さないためには、Gitのフィーチャーブランチごとに独立した検証環境を用意した。また開発環境と本番環境の間に本番環境と同じ条件のステージング環境を用意した。これにより、開発初期から実環境での挙動を確認できるようになったという。

 これをKubernetesで実現するために、検証環境のPodを実際の開発サーバーと同じクラスタの同じドメインで動かし、IstioのVirtual Service機能により、リクエストヘッダーでアクセス先を切り替えるようにした。

 同様にステージング環境も本番環境と同じクラスタで動かし、リクエストヘッダーで切り替えるようにした。これにより、ステージング環境を本番環境に昇格させるときもリクエストの向き先を変更するだけであり、切り戻しもできる。

新基盤の概要
検証環境とステージング環境を新たに用意

 続いて、シンプルで安全な運用だ。生のkubectlコマンドによる運用では、権限管理や学習コストの問題があり、また変更履歴が残らないのが問題だったと安田氏は言う。

 そこで、Gitリポジトリを中心にしたGitOpsの手法を採用した。設定をGitHubのGitリポジトリに集約し、クラスタは常にGit上の定義の状態に同期されるようにする。設定変更は必ずGitHub上のプルリクエストで行うことで、事前にレビューする。Gitなので、ロールバックもコミットをリバートするだけでよい。

GitOps
プルリクエストによって変更
GitOpsによるリリースフロー

 そして、一貫した監視だ。Istioにより、サービスに影響を与えず収集できる。そして、GKEとIstioで集めたログをStackdriverで集約して表示できる。これにより、監視手法、ログ、メトリクス、運用方法が統一されたと安田氏は説明した。

一貫した監視

 最後に、旧基盤からの移行状況も紹介された。現在、フロント寄りの部分から順に移行しているところで、バックエンド、特に永続データの移行は移行負荷が高いという。

旧基盤からの移行状況