ヘイブン・テクノロジーズがGitLabでKubernetesに移行した方法

ヘイブン・テクノロジーズは、ニューヨーク州ニューヨークを拠点とする保険技術ソフトウェア・アズ・ア・サービス（SaaS）プロバイダーです。ヘイブン・テクノロジーズになる前、同社は2015年にヘイブン・ライフというデジタル保険技術会社を立ち上げ、生命保険業界の変革に貢献しました。これにより顧客は見積もりを取得し、保険を申し込み、承認を受け、その保険をほぼ完全にオンラインで管理することができるようになりました。現在、ヘイブン・テクノロジーズは、そのユニークなクラウドネイティブ保険プラットフォームを生命保険、年金、障害保険業界の他の企業にも提供しています。その一例がヘルスブリッジで、これはCOVIDパンデミックの際に、マスミューチュアルが対象となる最前線の医療従事者やボランティアに無料で提供したオンライン生命保険です。これはヘイブン・テクノロジーズのソリューションを使用してわずか数週間で構築・提供されました。

保険技術会社として、ヘイブン・テクノロジーズは機密性の高い顧客データを保護する必要性を強く認識しています。同社のコードは価値ある知的財産であると、プラットフォームエンジニアリングマネージャーのエヴァン・オコナー氏は述べています。

ヘイブン・テクノロジーズはバージョン管理とソースコード管理（SCM）にGitLabを使い始めました。2019年までに、同社はGitLab CI/CDとコンテナレジストリを大いに活用していました。開発者は継続的に新しいプロジェクトを追加し、それぞれにDockerイメージの構築、ユニットテスト、回帰テスト、統合テスト、セキュリティスキャンを実行するパイプラインがありました。

初期のプロジェクトの一つは、すべてのDockerビルドをGitLabに移行し、そこでイメージを構築することでした。これにより、デプロイ時にイメージが事前に構築されテスト済みであるため、大幅な時間節約になったとオコナー氏は言います。

2019年後半、ヘイブン・テクノロジーズはスケーラビリティ、カスタマイズ性、セキュリティの向上を可能にするため、Helmチャートを使用してKubernetes上の自己管理型GitLabインスタンスへの移行を開始しました。それ以前は、ヘイブン・テクノロジーズはOmnibusデプロイメントを使用していました。これは最小限の設定で稼働できる、より一般的に使用されるインストール方法です。

Kubernetes導入前、チームはConvoxを使用していました。これはDockerとECS（Elastic Container Service）上に構築され、クラウド内のアプリケーションのデプロイと管理を容易にすることを目的としています。この設定は小規模な組織としてはうまく機能していましたが、オコナー氏によれば、最終的にはConvoxがクラウドリソースに対する十分な制御を提供しないという限界に達しました。ピーク使用日（特にリリース時期の周辺）には、GitLabが非常に遅くなり、ユーザーはUIで頻繁に500エラーを受け取り、パイプラインが失敗していたと彼は回想しています。

保険テクノロジー分野のイノベーターとして、ヘイブン・テクノロジーズのエンジニアリングチームは、GitLabのHelmチャートの早期採用者になるのに自然な適性があると感じていました。ヘイブン・テクノロジーズのリーダーシップには、製品が新しいため、GitLabのサポートとエンジニアリングチームからの支援を必要とする障害に遭遇する可能性があるという公正な警告が与えられました。

しかし、ヘイブン・テクノロジーズは怯みませんでした。「私たちのチームはKubernetesとHelmにやや不慣れでしたが、GitLabは私たちが学び、経験を積む機会となり、その経験を他のすべてのアプリをKubernetesに移行する際に活かすことができました」とオコナー氏は言います。

そしてGitLabはコミュニケーションをシームレスにしました。「GitLabのオープンソースコミュニティへの取り組みにより、難しい技術的問題を解決するためにエンジニアと直接協力することができました」とオコナー氏は言います。「全体として、あなたのチームがKubernetesに経験があるか、または私たちのように、最新技術を使用する目標と、すべての人のためにHelmチャートの改善に貢献したいという願望を持って未知の領域に挑む意欲があれば、Helmチャートの採用をお勧めします。」

GitLabのHelmチャートを採用する決断は、ヘイブン・テクノロジーズのすべてのアプリケーションをKubernetesに移行するという大きな動きの一部でした。ヘイブン・テクノロジーズがGitLab Helmチャートの早期採用者になることを決めたのと同時に、エンジニアリングチームは本番環境とユーザー受け入れテスト（UAT）環境全体をKubernetes上で実行するように移行する計画も立てていました。GitLabを他のアプリケーションと同じ方法でデプロイすることは非常に理にかなっていたため、すべての設定が一箇所にまとまるとオコナー氏は言います。

Kubernetesのもう一つの利点は、自動スケーリングと高可用性がソフトウェアにネイティブであり、Helmチャートを通じて簡単に有効にできることでした。「複数のEC2インスタンスの方向に進んだ場合、自動スケーリングと高可用性のためにそれぞれ独自のソリューションを必要とする多くの異なる設定を管理しなければならなかったでしょう」とオコナー氏は言います。

Kubernetes上でGitLabを実行するための最初の前提条件はクラスターを構築することです。ヘイブン・テクノロジーズの全アプリケーションがAWSに存在するため、Amazon EKSを選択しました。エンジニアはUATと本番環境の両方にGitLabを構築することを決定し、本番環境に移行する前にアップグレードやその他の設定変更をテストできるようにしました。

ヘイブン・テクノロジーズはJiraとTerraformを使用し、GitLabパイプラインを使用してTerraformタスクを自動化しています。

オコナー氏は、安定性を維持し、難しいアップデート中のデータ損失のリスクを減らすために、GitLabのステージング環境を維持することを強く推奨しています。「GitLabはこれを容易にし、両方の環境をサポートするために必要なライセンスは1つだけです」と彼は言います。「TerraformとHelmを使用して、UATと本番環境はほぼ同一に構成されており、UATではコスト節約のためにより控えめなスケーリングを行っている点だけが異なります。」

将来的には、オコナー氏はエンジニアが不要な時にアイドル状態のマシンが稼働しないよう、UAT GitLabシステムを簡単にシャットダウンまたはスピンアップする方法を構築することを目指すと言います。

もう一つの課題は、本番環境に切り替える前にUATセットアップの負荷テストを行う方法を見つけることでした。開発とQAチームからのボランティアがGitLabの負荷テストを行い、異常を探すよう依頼されました。オコナー氏のチームはスプレッドシートを作成し、ユーザーに見つけた異常を入力してもらいました。これにより、完全に切り替える前にいくつかの設定ミスを修正することができたと彼は言います。

エンジニアは本番環境のGitLabシステムをKubernetesに切り替えた後、Helmチャートのモニタリング部分を構築しました。これにより、負荷によって引き起こされる問題の診断が特に困難になりました。当時、彼らが持っていたのはKubernetesクラスターによって報告されるポッドレベルのCPUとメモリメトリクスだけでした。これらのダッシュボードは、ポッドの制限が控えめに設定されすぎていた問題を解決するのに役立ちました。

ヘイブン・テクノロジーズはまた、AWS CloudWatchメトリクスとログクエリを利用して、ボトルネックを探し、AWSリソースの問題と関連付けました。

今後、Kubernetes上のGitLabをテストする際に問題が発生した場合、オコナー氏は問題をより迅速に特定するためのダッシュボードを作成すると言います。

GitLabパッケージレジストリを使用することで、ヘイブン・テクノロジーズはパブリックnpmレジストリの使用を停止することができました — これにより150人以上のユーザー（2022年12月23日現在）あたり月間$7のコスト削減が実現しました。自動スケーリングのDocker-machineとKubernetesランナーを実装することで、オコナー氏のチームは開発者ブランチへの各コミットに対して実行される回帰テストと統合テストの数を増やすことができました。

チームはまた、各マージリクエストで実行するセキュリティパイプラインの数を大幅に増やし、開発ライフサイクルの早い段階でアプリケーションのセキュリティ確保に開発者の関与を高めるのに役立てています。

全体として、GitLab CIを使用することで、特にブランチング周りの多くのプロセスを自動化し、開発者の時間を解放することで、ヘイブン・テクノロジーズのソフトウェア開発ライフサイクルに価値を追加しています。