ID:73585さん

# プロジェクト概要（目的・人数・体制） 自社サービス（楽楽シリース）の実行基盤としてKubernetes、及び、エコシステムを構築するプロジェクトです。 体制はインフラチームが4名、SREチーム（自チーム）4名、開発チームが多数（複数のサービスが関係していますが、アドバイザの色合いが強い）となっていました。 SREチームは全体を率先する立場で、私はプロジェクトのマネジメント兼、設計と開発も担当していました。 # プロジェクトにおける自身の役割 Kubernetes基盤、CI/CDのパイプライン、エコシステム（Argoシリーズ、Vault、Manifest管理ツール導入）などプラットフォーム全体の設計を行いつつ、それらの実装も担当していました。 また、リードするチームのマネージャーとしてプロジェクト全体のマネジメントや意思決定も行っていました。 # 当時の背景/抱えていた課題と対策 人数を増やしても思ったように機能提供の速度が上がらないという問題を抱えていました。 状況を整理すると以下の2つが課題であることが見てきました。 - モノリシックなアプリケーションのため変更のコストが高い - 人手でデリバリ作業をしており準備や調整のコストが高い 対策として機能によるサービス分割、コンテナ技術導入によるデリバリコストの低減を提案し、SREチームとしてそれを牽引することとしました。 # 課題へのアクション ### 進め方 サービス分割については、SREチーム単体で進める事が難しかったため、単独でも進められるコンテナ技術導入（Kuberenetesの導入）を進めました。 最終的にはコンテナ移行した上でサービスも徐々に分割していく様な計画となっています。 ### 使用した技術 - Kubernetes基盤 : VMware Tanzu - これまでインフラチームがVMwareを仮想基盤として利用していたこともあり、そのノウハウを流用しながら慣れたツールで運用出来るという点でTanzuを採用しています。 - マニフェスト管理ツール : Helm / Helmfile - マニフェスト管理ツールとしてHelmを採用、環境によって切り替えるケースなどHelmだけで不足する場合はHelmfileも合わせて利用しています。 - デリバリツール : ArgoCD - ラクスは複数のサービスを運用しているため、各サービスごとにKubernetesのクラスタは独立させ、それらを集中管理するための専用クラスタ上にArgoCDを構築しています。 - 各サービスごとにArgoCDのプロジェクトを作成して、権限を分離するように設計しています。 - バッチの管理ツール : Argo Worfflows / Argo Events - 定期的なバッチの投入や一過性のジョブを投入するための基盤としてArgo Workflowsを導入しています。 - 他のシステムとの連携のためにArgo Eventsも利用しており、Argo Events経由でArgo Workflowsにも連携しています。 - シークレットの管理ツール : HashiCorp Vault / Vault Secrets Operator - シークレットを管理するためにKubernetes上にHashiCorp Vaultを構築しています。 - 各サービスのKuberrnetesクラスタと連携するためにVault Secrets Operatorを採用しています。 - オブザーバビリティツール : Grafana Stack（Prometheus, Loki, Tempo） - o11yツールとしてGrafana Stackのツール群を採用しています。 - コストを抑えて小さく始めるために自社で運用する方式にしています。 - o11yツールについては設計と技術選定のみとなっています。 - CI/CDのツール : GitHub Actions - GitHub ActionsのReusable Workflowsにて共通的なCI/CDのワークフローを提供しています。 - CI/CD以外でも定期的なコンテナイメージのスキャンなど共通的に利用するワークフローの作成も担当しています。 Gitリポジトリについて元々は社内でGitLabを運用していましたが、メンテナンスコストが高いこと、CI/CDが拡充されていないことが課題としてありました。 今回のプロジェクトに合わせて、GitHubへ移行することでメンテナンス無くし、よりCI/CDが組みやすい環境へ移行するといった対応も合わせて行っています。 ### その他の施策 構築した環境を有効活用してもらうために、会社内のエンジニア向けの勉強会や、ハンズオンなどSREチームとしてのイネーブリング活動も実施しています。 # 課題に対して自身が発揮したバリュー及び成果 SREチームとして、その長として率先して動く事で改善をしていく文化情勢に寄与できたと思います。 定期的にSREチームから成果発表も行っていたので、これまで諦めていた現場のモチベーションにも繋がっています。 構築した環境は2024年度に3つのサービス（既存サービスや新サービスなど）で実運用が開始予定となっています。 並行して更に他のサービスにも広げる動きがあるので、今回のプロジェクトの成果はエンジニア組織全体への貢献になっていると考えています。

# プロジェクト概要（目的・人数・体制） 契約に合わせて各サービスへアカウント解説、契約変更などの指示を出す共通の基盤システムのリプレイスを行っていました。 体制はSREチームが5名、私はプロジェクトマネジメントと設計に携わっていました。 # プロジェクトにおける自身の役割 SREチームが管理しているシステムとなっているため、現状の課題と改修コストなどを整理した上でプロジェクトの立案とそのマネジメントを主に担当していました。 2023年度に並行して進めている自社DCへのKubernetes基盤導入とも連携しており、そちらで構築したエコシステムの導入なども担当しています。 また、私が現行システムのドメインに詳しい状態でしたので、要件や仕様のレビューなども担当していました。 逆に詳細な設計や実装などはメンバーに移乗し、各自に自走してもらう体制で進めていました。 # 当時の背景/抱えていた課題と対策 当該システムは構築されてから時間が経過しており、構築当初に考えていたスループットでは今後の契約件数の増加耐えられないことが試算結果から明白になっていました。。 また、ドキュメントなども残っておらずツギハギのコードはメンテナンス性が低く、サービスを運用する基盤としてもリスクを抱えていると考えていました。 場当たり的な対応ではシステム的にも限界が来ること、属人性の高いシステムはコアメンバーの退職などによる崩壊のリスクがあることを関係部署へ説明し、リプレイスするプロジェクトを立ち上げることとしました。 # 課題へのアクション ### 進め方 SREチーム発案のプロジェクトですが、契約管理を担当するビジネス部門の業務と非常に関係性が高いものとなっていましたので、当該部門と巻き込んで現状のシステムや業務を元に要件再整理して、その情報を元に開発を進めました。 ※契約管理の担当部門が処理したデータに合わせてユーザのアカウントを解説したり変更するため、この部門はシステムのユーザに該当する RDRAとDDDを利用して現行のシステムからバックトレースで要件を定義、それを元に再設計しながらドキュメントも整備していくような進め方をしていました。 ### 使用した技術 - 開発言語 バックエンド : Go - フレームワーク : Gin, gRPC:buf - Kubernetes基盤 : VMware Tanzu - DB : CloudNativePG - マニフェスト管理ツール : Helm / Helmfile - デリバリツール : ArgoCD - バッチの管理ツール : Argo Worfflows / Argo Events - シークレットの管理ツール : HashiCorp Vault / Vault Secrets Operator - オブザーバビリティツール : Grafana Stack（Prometheus, Loki, Tempo） - CI/CDのツール : GitHub Actions また、新しい技術的の導入としてgRPCを利用したマイクロサービス構造のアーキテクチャを採用しました。 ### その他の施策 レガシーシステムのリプレイスで元々の要件が不明瞭な部分が多かったため、 RDRAを利用してバックトレースで要件を可視化してユーザ部門と要件を再定義していました。 # 課題に対して自身が発揮したバリュー及び成果 要件の再定義の際、メンバーやユーザー部門のメンバーが現行のシステムの仕様に引っ張られがちでしたが、そもそも業務上で本当に必要なことは何なのか？ ということを問うことで必要な機能に絞ってシンプルに要件を整理出来るようにサポートしました。 ※リードしすぎるのはチームの成長を阻害するのでフォローがちょうど良いと判断 また、SREチームとしては今後もKubernetesやマイクロサービス化をリードしていくという目標を掲げているので、技術選定時にそこを強く意識する様にしました。 その際、マネージメント層が決定して下ろす形は成長を阻害するのでメンバーに提案のタスクをアサインするようにしました。 提案時も複数の選択肢を考え、それぞれのメリット・デメリットをしっかりと説明してもらった上で判断する形を取ることでメンバーの育成も意識しました。

# プロジェクト概要（目的・人数・体制） 契約者向けに契約内容の確認や変更を行うためのポータルサイトの開発を行っていました。 体制はSREチームが6名、フロントエンドのエンジニアが1名となっており、私はプロジェクトマネジメント兼、設計と開発にも携わっていました。 なお、2023年度の取り組みにも繋がるのですが、自社のDCでKubernetes基盤を構築することも検討していたため、本プロジェクトPoC的な立ち位置も兼ねていました。 SREチームはアプリケーションエンジニア出身のメンバーを採用していたため、プロジェクトを進める上でも障壁は無いと判断した上で対応することとしました。 # プロジェクトにおける自身の役割 プロジェクトの立案、人員の採用及び、プロジェクトのマネジメント、アーキテクチャ設計を担当していました。 今後の展望を見据えて、技術選定では採用実績の無いKubernetesなどを利用するなど、アーキテクチャの設計などもリードしつつプロジェクトを進行しました。 # 当時の背景/抱えていた課題と対策 契約管理部門としては、契約の変更や内容の確認を人手で対応していることでの人的なコストが肥大していること、また繁忙期（月末や年度末など）には対応に時間が掛ることに課題を持っていました。 上記のビジネス的な観点とは別にエンジニアリング部門としてはデリバリ速度の向上に新技術（コンテナ技術）を導入したいが、既存サービスへの導入に踏み切れ無いという課題を持っていました。 本プロジェクトは契約管理の作業を自動化するというビジネス課題を解決すると共に、将来的な技術刷新のためのノウハウを集めるといったエンジニアリング部門の課題にも対応する事も目的としていました。 # 課題へのアクション ### 進め方 システム化を要望した部門は契約管理が専門の部隊でシステム開発についての知見が全く無い状況、SREメンバーも新規に採用したメンバーばかりでドメイン知識を持っていない状態でしたので、しっかりとドメイン知識を付けつつ進める方針としてDDDを採用し、皆でドメインを理解しながら開発を進める様な体制としました。 ※私は古くからいるメンバーなので持っている情報をメンバーへ渡していく立場で動いていました 技術的な面ではコンテナ技術を利用することを前提としていましたので、Kubernetesを中核に置いてエコシステムを選別していく形でアーキテクチャを決定していきました。 メンバーの数は限られており、初採用の技術が多い事が想定できたので全てを時前で用意することは止め、可能な限りAWS上のマネージドサービスを活用する方針としました。 なお、将来的にはオンプレ環境にKubernetes基盤を構築することを検討していたので、この部分は死守する様にしていました。 また、SREチームはKubernetesに触るケースが多く、コントローラー開発やトラブル時のデバッグなども想定して、本プロジェクトよりチームの共通言語としてGoを採用するという判断をしました。 ### 使用した技術 - 開発言語 バックエンド : Go - 開発言語 バックエンド : TypeScript + Next.js - Kubernetes基盤 : AWS EKS on Fargate - 運用における人的リソースを削減するためにFargateを採用しています。 - DB : Amazon Aurora PostgreSQL - その他のAWSリソース : Cognito、SQS、SES、S3、ElasticCache - IaCツール : Terraform - マニフェスト管理ツール : kustomize - なるべく学習コストを抑えるためにより素のマニフェストに近いkustomizeを採用しています。 - デリバリツール : ArgoCD - オブザーバビリティツール : Datadog - o11y系の基盤構築、運用のリソースは避けないため外部サービスを選択しています。 - CI/CDのツール : GitHub Actions - CIで利用可能な部品が多くCIの構築を簡略化するために利用 ### その他の施策 Kuberentesについては私は個人的に学習していたので知見がありましたが、SREチームとしては知見がない状態からのスタートだったので、書籍を用意して輪読会で知見を深める活動をも行いました。 Goについてもチームメンバーが始めて利用する言語だったので、各々が学習した情報を持ち寄ってスプリントの振り返りに共有する場を用意することで学習意欲を高める様な施策を行いました。 # 課題に対して自身が発揮したバリュー及び成果 システム開発の経験がない部門から必要なドメイン知識をしっかりと引き出して開発を進められたこと、新規に採用した技術をしっかりと習得して活用できていたと思います。 その実現のためにマイクロマネジメントはせず、メンバー自身が考えて提案し、実際にチャレンジ出来るようなマネジメントを心がけていました。 とは言え、メンバーに丸投げにはならないように設計のレビューには参加し、技術的、ビジネス的に大きな決定の際はメンバーから必要な情報を集めてしっかり判断することにも注意を払って対応しました。