こんにちは!
開発プラットフォームグループ 基盤チームのリーダー兼システムアーキテクトの木村です。
今年の9月から基盤チームが新設されました。
少し遅くなりましたが、今回はなぜ基盤チームが新設されたのか？等を赤裸々にまとめてみました。
ビザスクのシステム歴史について
ビザスクでは、2012年創業以来、GCP(GAE) + Python2の構成で、ナレッジプラットフォームという概念を広めるために様々な試行錯誤を繰り返しながら、サービスを拡大していきました。
この ゼロイチ のフェーズの間に、様々な機能やサービスを作り、失敗をして、学びを繰り返して現在に至ります。
サービスの拡大でシステムは肥大化していき、アーキテクチャやインフラは取り残されたままだった
当然のことながら、失敗した施策や機能があればシステム的にはだんだんと複雑になり、肥大化していきメンテナンスコストが上がってきます。
またサービス拡大期のフェーズに適切に技術負債の解消をできれば良かったのですが、エンジニアの人数が少ない中で、そのリソースを割くことがその当時はきっと難しかったのでしょう。
(その当時は私はまだビザスクにJoinしていませんでしたので、想像です)
また2019年以降、開発メンバーの人数も急激に増え始め、抜本的なシステム改善をしなくてはまずい。という雰囲気を感じながらもどのようにやっていくか？どのチームがやっていくのか？の打ち手が中々出てきませんでした。
サポート切れのPython2からの脱却に向けてタスクフォースチームを編成する
そこでまずは、サポート切れのPython2 をPyhton3にアップグレードしようと決断をして、アップグレードを行う為に期間限定のタスクフォースチームを結成し、Python3にアップグレードをするための前哨戦というべき、対応を行いました。
(下記の図はやった対応の一部です)
この時に私は、SREとしてPython3アップグレードのサポートしていました。
ユーザーや組織が加速度的に増えていくフェーズで、システムの抜本的な改善をしなくてよいか？という問い
当初の目的は、今のシステムに対して、Pythhon3に載せ替える。がミッションでしたが、インフラ面やアーキテクチャが刷新されていないプラットフォームにそのまま乗り換えても良いのか？という疑問を私が持ち始め、VPoEと議論をした結果、スコープを大きく広げて、Python3 に移行する。という考え方から、システム、設計を 3年後を見据え、3年後に想定されるであろう組織体制に耐えうるように思い切ってリプレースする。という決断をエンジニア組織全体で行いました。
システムリプレースでの大きな変更点
システムリプレースでの大きな変更点は下記になります。
新しい Google Cloud プロジェクトに移行
ビザスクでは、サービスのインフラストラクチャにGCPの全面採用をおこなっているのですが、既存システムに影響しない形で全体の移行を進めたかったので、既存のGCPプロジェクトに新システムを載せる形ではなく、新しいGCPプロジェクトに新システムを載せました
Legacy AppEngine for Python2からCloud Runへの移行
当初は最近作ったシステムでAppEngine Flexibleを利用していたシステムがあったので、それに乗り換える予定でしたが、Compute サービスの中で最も汎用的に利用ができそうかつ、GCPの積極的なアップデートを行っていてサービスの拡充に未来がもてた為、Cloud Runに 移行しました。
サービス分割
ビザスクは今まで複数の開発チームにモノリシックなリポジトリ構成で開発を行っていましたが、開発メンバーも30名以上となった現在、モノリシック構成で開発を続けていくと、ハード(仕組み)の制限によって中央集権気味な意思決定をせざるを得ない、いわゆる コンウェイの法則 から抜け出す為にサービスをマイクロサービス化にしました。アーキテクチャ上はドメインレイヤーから大きく4つに分割しました
Infrastructure as Codeの全面採用
部分的に利用していた Terraform を全面採用して、開発者に渡している個人GCP環境にシステム再現率約98%以上のシステムを複製できるようにしました。
これを行うことによって、アプリケーションエンジニアがシステム課題に立ち向かう時にインフラを気軽に試せるようになり、クラウドコンピューティングを利用して課題を解決するか？それともアプリケーションで解決するか？の選択肢を増やすことができる。という意図のものに手動インフラの構築を徹底的に排除しました。
IAMの管理をメールアドレスからGoogle Groupによるグループ管理へ
組織規模が大きくなってくると権限問題が必ず発生します。ですが、メールアドレスベースで管理をすると、権限付与を行う時にどうしても煩雑なオペレーションになってしまい、結果、権限を渡す側も権限がほしい側も億劫になる。というのを避けるためにグループ管理に切り替えました。
こちらの詳細は別途記事にしたいな。と思っています。
本当にできるのか？という空気感の中での新システム移行のプロトタイプの作成と挫折の繰り返し
決断も難しいですが、作るのも難しいリプレース。最初の半年は当初引いていたマイルストーンの遅延の繰り返しと、てんこ盛りに機能がある既存システムを本当に入れ替えれるの？的な空気感が漂い、希望と挫折の繰り返しでした。
模索している最中に意見や考え方の違いによる対立等もしばし、発生しました。
また、タスクフォースのメンバーはその当時4名でタスクフォースメンバーだけでシステムリプレースをするのは不可能です。
しかしサービスチームはグロースのミッションをもっており、スケジュールの調整も超絶難しく難航しました。
あんまりにも辛くて春頃は一瞬辞表書こうかな。位辛い時期もありましたw
今思い返すと、リプレースプロジェクトは闇の底まで落ちていた時期でした。
エンジニア組織全体での３年後のシステム中長期計画を作って改めて全体でのシステム課題等の認識をあわせる
システムのプロトタイプがある程度出来上がったタイミングで改めて
- 何がシステム的に課題なのか？
- 何をシステム的にどうするのか？
- このプロジェクトの3年後の最終的に目指すゴールは何か？
をエンジニアリーダー、VPoE、VPoP全員と改めて議論をしました。
これは自分のプロダクトマネージメント能力の低さが原因なのですが、自分は周りに話したつもりでいたし、何回も説明をしたつもりだったが、実際は周りがついていけていなかった。が原因でした。
この話したつもり状態ではやはり温度感が合わず、大きく事を進めていくためには認識合わせに時間をかけて、何回も議論を重ね、ゴールを擦り合わせる事が重要だな。というのを深く学びました。
その際に忙しいエンジニアリングリーダーの皆さんは辛抱強く時間を割いていただいたのは感謝しかないです。
また壮大なマイルストーンをエンジニア組織だけで決定できるわけもなく、経営陣にも説明をさせていただきましたが、快く前向きな返答をもらったのは、テクノロジーの重要性を理解しようとしている会社であって、良かったな。と心底おもいました。
体制を再整備して底から抜け、基盤チームの新設へ
長い暗闇から抜けて、徐々にシステムリプレースにJoinするチームが1チームから2チーム、2チームから3チームと増えてきて、一気にシステムリプレースのアクセルが踏まれ始めました。またマイクロサービス化を実際に行ってくと、車輪の再開発をしない為に共通処理を一元管理する必要性が高まって来ました。
これから認証中央基盤の作成や、よりマイクロサービス化を推進するための仕組み作り、クラウドインフラと掛け合わせた、よりリリースサイクルを早めるための仕組み等を専門にやるチームが必要性が見えてきたので基盤チームの新設になりました。
タイトルから結論までが大分長かったのですが、この一年の間に色んな困難があったので、長くなってしまいましたw
システム面で大きな転換期を迎えているビザスクでは基盤チームのメンバを募集しています
はい。で最後に宣伝なのですが、基盤チームではまだまだやらなくてはシステムの構築や環境整備等、ゼロベースから考えられる課題やシステムが沢山あります。
0 -> 1ベースや泥臭い事等、この記事を読んで共感を持たれた方は是非 こちら から連絡いただけると嬉しいです。
大分な量がありましたが、最後まで読んでいただきましてありがとうございました。
