PROFILE
見形 親久
SRE課 課長
大学卒業後、SIerへ入社。何度かの転職を経験しつつ、PG、SE、PMと進みながら、システム開発の経験を積む。 2015年ラクスへ入社、楽楽精算の運用チームを設立後、SREチームを立上げ、現在SREチームのマネージャーをしている。
SRE課についてご紹介をお願いします。
以下のミッション・ビジョンを掲げて活動しています。
・ミッション：開発組織のDevOps文化を醸成しプロダクトの価値を高速に提供する
・ビジョン：開発とインフラを繋ぐHubとしてモダナイズを実現する
現状はリリースから時間が経過したシステムも多く、色々な技術負債が蓄積している状態になっています。クラウドネイティブな技術を用いることでこれらの課題を解消し、より早く顧客へ価値を届けられる様な環境を構築することを目指しています。
なお環境の構築については、システム的な面は勿論ですが、クラウドネイティブな人材の育成や文化の醸成といった面も含んでいます。システムを用意するだけに留まらず、実際にそれを利用して効果が出せるようにイネーブリングしていくことも業務の一環と捉えています。
今回はクラウドネイティブの土台となるコンテナ化推進事例についてご紹介いただきます。まずはコンテナ化を進める前の問題意識と課題について教えていただけますか？
機能リリースまでの時間はもっと短縮化できると思っています。時間がかかる要因は様々ですが、重要な要素として巨大なモノリシック構造になっている事があげられると思います。
運用歴が長いものなど、プロダクトによってはコードが複雑に絡み合っており、改修時の影響調査や動作確認に掛かるコストが高くなっています。リリース作業に於いてもビックバンでのリリース作業となっており、そのために手順が複雑化し、発生しうるトラブルのための事前調整などのコストも膨大なものとなっています。
これらの問題を解決するには機能を分割して、影響範囲を限定的な状態にした上で、細かく修正、リリースを繰り返せる環境を作っていくことが重要になってきます。そのための重要なファクターとしてコンテナ技術があると考えています。
今回のコンテナ化の概要について教えてください。
楽楽電子保存をコンテナ化のターゲットとしています。
こちらのプロダクトを選んだ理由としては、ローンチからまだ日が浅く比較的規模が小さいこと、システムとしての技術負債が少ないことが挙げられます。まずは、当該プロダクトでコンテナ化へのノウハウを蓄積して、それを他のプロダクトへも展開していく想定です。
取り組みとしては、アプリケーションをコンテナへ移行することは勿論ですが、コードプッシュを元にしたCI/CDや実際に運用する上で必要なObservability基盤の導入なども進めています。
2023年7月より動き出していますが、年内はPoC期間として必要なツールの選定や検証環境での動作確認を進めています。2024年に入りましたら、実際の本番環境での運用を目指して運用ルールの整備や担当メンバーへの教育なども実施する予定です。
その取り組みの目的と目標とする成果はどのようなものでしょうか。
まずはコンテナ化とCI/CDに注力していますので、機能リリースのための準備時間や実際のリリース作業の時間短縮、ミスの低減というもので成果を測ろうとしています。ただし、これはあくまで効果の一端でしかないと思っています。
コンテナにすることでリリースの手軽さを体感できれば、小さく早く出したいという思いも強くなり、より疎結合で小さなアーキテクチャへの刷新も進むと考えています。
結果的により疎結合に、より早く、小さくしたことで品質も担保できるといったプラスのサイクルが、DevOpsのサイクルとして回る様な状態になることが目指すところであり、それによる価値提供の高速化が成果だと考えています。
具体的にはどのように進めていったのでしょうか。
まず各社の事例を収集するところから始めました。
幸いな事に、Cloud Native Days、SRE-Next、Platform Engineering Meetupなど様々な場所で学習する機会がありましたので、そちらへ参加しつつ自分達の作る環境のイメージを固めていきました。
あまり細かく記載できないのですがざっくりと環境について説明すると、弊社はVMWareの仮想環境で運用を行っているため、VMWare tanzuを利用したKubernetes基盤をベースにした環境を検討しています。CI/CDのランナーとしてGitHub Actionsを利用しつつ、Kubernetes環境へのデプロイにはArgoCDを利用したGitOpsを採用しています。
オンプレの資源が大量にあることを利用して、Observability基盤のGrafanaスタックの環境を構築していたり、Secrets管理基盤としてHashicorp Vaultも自前で運用しようとしているのは特徴的な部分ではないかと思います。
進めるうちにどのような技術的課題が発生しましたか？
Kubernetesを導入するにあたってマニフェストのテンプレート化やそれに伴うGitのブランチ戦略はなかなか頭を悩ませているところです。
最初はなるべく可読性が高いものを利用したいということでkustomizeを利用していましたが、Gitブランチの戦略とうまく噛み合わない部分が出てきたため、helmチャートへ切り替えています。
ここについては、正直なところ正解だったのか分かっていません。現時点では開発・運用の流れとマッチしていますが、規模が拡大する中でエッジケースも出てくると考えています。そのため、事前に課題を洗い出す方法は取らずに、まずは試して運用に載せてみるという流れを大切にしています。
まだまだ、これから始めるというステップなので考慮不足は大いにありますが、そこを気にしていると進みが悪くなってしまうのでまずは、進めること、問題が出たらそれを一つずつ解決していくというシンプルなスタンスで対応するようにしています。
現状の進展について教えてください。
年内に予定していたコンテナ環境でのPoCまで完了しています。
ここまでは検証用のKubernetes環境で主にアプリケーションの動作確認と開発フローをGitOpsに乗せるための諸々の確認を行ってきました。
今後は、実際に実機を利用した環境への移植や性能検証、Observability基盤の構築やOpenTelemetryに対応するためのアプリケーションの計装などを進めていくことになります。
またシステムの整備と並行してメンバーの育成にも力を入れていく予定です。現在はクラウドネイティブな技術の知見がSREチームのメンバーに集中してしまっています。
実際に実運用になると開発チーム、インフラチームに見て頂く部分が多くなるため、彼らが構築した環境を扱える様になるためのサポートも積極的に行っていく予定です。
今後の展望について教えてください。
コンテナ化を皮切りにクラウドネイティブ技術の導入を推進していきたいと考えています。
具体的にはObservabilityの拡充であったり、SLI/SLOの策定、エラーバジェットの導入といった信頼性向上の動きを強めつつ、コンテナ技術をうまく利用出来るようにマイクロサービスへのリアーキテクトを推進したいと考えています。
またシステム的な面は勿論のこと、書籍「チームトポロジー」にあるようなプロダクト思考の組織作りも並行して進める事で、SRE課がイネーブリングチームもしくはプラットフォームチームの立ち位置となり、システムだけではなくそれを開発・運用する組織もクラウドネイティブ化していきたいと考えています。
