初めまして、JCB デジタルソリューション開発部の平松です。
この度、弊社JCBでは「思いついたビジネスを素早く市場に提供する」ことを目指して新たにKubernetesを軸としたマイクロサービスを構築するために新規プラットフォームを開発しました。
そして、ビジネス着想からリリースまでの期間を短くするためにビジネス部門とシステム部門が一体となって開発するサービス開発組織を立ち上げました。
その組織での活動の一環として、JCB社内の取り組みを発信するためにエンジニアリングブログを開設しました。
第一弾となる今回は、プラットフォームで利用している技術を紹介いたします。
サービスプラットフォーム
基本はGCPを用いています。
アプリケーション実行基盤として採用したGKEがKubernetesの運用面(バージョンアップが容易である等)での有用性が高く、その他にも魅力的なサービスが備わっていることが導入の決め手です。
中でもCloud Spannerは、99.999％の可用性を持っていたりマルチリージョンで稼働してどのリージョンにデータをInsertしても他方にも即座に反映される仕様です。
内部でも”どうなってるのか意味がわからない”と会話しているくらい素晴らしいサービスです。
ぜひ詳細な仕組みが知りたいものです。
プラットフォームの構成パターンについて説明します。
オンプレミスやインターネットといった外部との接続設定についてはCommon Services Hostの中に集約させ、各アプリケーションのHost ProjectとはVPC Peeringでつないでいます。
アプリケーションの実行環境はGKEです。
GKEのクラスタは基本的に各アプリケーションで共有し、namespaceでアプリケーションを分割します。
各アプリケーションには当然ストレージなどといった固有のサービスが必要となります。
それらを設置するためのサービスプロジェクトをアプリケーションごとに作成し、必要に応じてGKE内のnamespaceと連携して通信します。
マイクロサービス基盤
マイクロサービスには当初セルフホストでのIstioの運用を考えていましたが、Anthos Service Mesh導入の際のGKEのチャンネルの選択の幅が拡がった1ことから、マネージドIstioであるAnthos Service Meshを導入することを決定いたしました。
Anthos Service Meshによるトラフィックの可視化・負荷分散など、今後の運用に活用したいと思います。
Infrastructure as Code (IaC)
GitOpsとして、ソース管理をGitlabで行っています。
GCPのリソース作成に関しては基本的にTerraformを用います。
Kubernetesのマニフェストと合わせて、基本的には開発環境を除くQA(Quality Assurance)・ステージング・本番環境は全てIaCにて管理していきます。
ただし開発環境は開発者の自由にサービスとかを試してもらうため、IaCオンリーの制限は設けません。
本プラットフォームは裏テーマとして、DX(Developer eXperience)の向上を掲げており、品質を担保した上での最新技術の取り込みは常にウェルカムな状況です。
CICD
CIに使うのは、Gitlab CIです。
各アプリケーションは、CI Runnerによってビルド・テスト自動実行などを走らせた後に作成したコンテナをGCRに格納します。
CDに関してはOSSであるArgo CDを用います。アプリケーションによって様々な公開手法が考えられるため、今後Argo Rolloutを導入することでカナリヤリリース等にも対応可能であることから選定しました。
セキュリティ
開発したアプリケーションに関するセキュリティ対策として、パロアルトネットワーク社のPrisma Cloudを導入します。
これにより、CSPMとCWPPという2つのセキュリティ基準を満たすことができます。
また、CIの一環でPrisma Cloudによるイメージスキャンを実施することで、アプリケーションの開発段階において脆弱性チェックを効率よく実施できます。
本番運用中に発生した問題についてもPrismaを利用していれば、Incident Explorer や Forensicによってインシデント発生時のコンテナの挙動を事後調査可能と見ています。
モニタリング・APM
サービスの運用監視は、DatadogとPrometheusなどの各種OSSを利用します。
アプリケーションとプラットフォームで異なるダッシュボードを用意し、インシデント発生時の初期の切り分けが容易となるように設計いたしました。
Datadogだけだと万が一Datadogが倒れた際にサービスの不具合が検知できなくなるので、その保険としてPrometheus等のOSSを組み合わせて第2の監視基盤を構築します。
この二重の体制でサービスの運用しています。
インシデント管理
運用時のオンコール制御として、PagerDutyを導入します。
PagerDutyを使うことにより、DatadogやPrisma Cloudから出力されるインシデントを検知し、手早く管理者へ通知できます。
選定の決め手は、オンコールスケジューリングを使うことによって、当番制の通知ルールを作ることができる点です。
これに加えて、Event Interigenceアドオンを追加することでアラート抑制機能が利用可能になる点がポイントでした。
本機能により過剰に同件アラートが発生した場合にオンコール担当者が疲弊したり正常な判断ができなくなる恐れを解消できると考え、採用しました。
まとめ
今回はJCBが取り組んでいる新規プラットフォームの実行・運用環境周りを中心に説明していきました。
他にもプラットフォームチームとしては、ゼロトラストな開発環境を設計・構築していますので、そちらの話も今後は記載していきたいと思います。
もちろんアプリの話題もアプリケーション開発チームを中心に投稿を予定しています。
個人的にもまだまだGCPの設計の細かい勘所については把握し切れていないので、その辺りの情報も今後まとめていけたらと思います！
終わりに
紹介したプラットフォームについては、Google Cloudの事例として紹介されています。
今後は大きな話題から小さな話題まで、様々なテーマで投稿していこうと思っていますので、今後ともよろしくお願いします。
最後に、JCBでは我々と一緒に働きたいという人材を募集しています。詳しい募集要項等については採用ページをご覧下さい。
最後まで読んでいただき、ありがとうございました。
-
Anthosの検討時期では、最新版がサポートしていたGKE バージョンはRegularチャンネルのみでStableが選択できない状態でしたが、解消されました。↩
