皆さんの職場には、SREチームや全社的な基盤チームはありますか？私の職場にはそうした専門チームがあるのですが、最近、あるプロジェクトでマイクロサービスを新規開発することになりました。その過程で、プロダクト開発チームと、SREや基盤といった専門家チームの間に立ち、気づけば「翻訳家」のような役割を担っていた、という話をします。
なぜマイクロサービスを開発することになったのか
ことの発端は、ある機能追加の検討でした。
その機能で扱うデータが、非常に大規模なものだったのです。既存のモノリシックなアプリケーションのDBにそのまま追加してしまうと、パフォーマンスの低下は避けられませんし、最悪の場合、システム全体を巻き込む障害につながる可能性もありました。
また、そのデータは将来的に他のサービスからも参照される可能性が高いものでした。
「なので、マイクロサービスを立てましょう」
システムの安定性と将来的な拡張性を考え、このアーキテクチャを選択するに至りました。こうして、私のチーム間翻訳家としての役割がスタートしたのです。
チーム間の翻訳家、誕生
マイクロサービスを作ると決まっても、プロダクト開発チームだけで開発が完結するわけではありません。サーバーやDBを準備してくれるSREチーム、社内の認証基盤などを提供してくれる基盤チーム。こうした専門チームの協力なくして、サービスをリリースすることはできません。そこで、私がハブとなり、各所との調整に奔走する日々が始まりました。
最初の関門、サービスの名前決め
インフラ構築を依頼するにも、まずはサービス名がなければ話が進みません。「どんなサービスか」を的確に伝えつつ、覚えやすい名前を考える。これは意外と重要なプロセスです。関係者と議論を重ね、シンプルなサービス名を決定しました。
インフラ構築のキックオフミーティング
名前が決まったら、次はSREチームへのインフラ構築依頼です。設計書をもとに「こういうサービスで、これくらいのアクセスが想定されるので、リソースはこれくらい必要です」といった要件を伝えるミーティングを開きました。この段階で関係者間の認識をしっかり合わせておくと、後の手戻りを大幅に減らせるので非常に重要です。
デプロイスクリプトの準備
サーバーの構成が見えてきたら、次はCI/CDの構築です。幸い、社内にはリポジトリの雛形を簡単に作れる便利なツールがあったため、基本的な部分はすぐに構築できました。とはいえ、プロジェクト固有のデプロイ処理などは、自分でスクリプトを書く必要があります。ここは基盤チームの方々にアドバイスをいただきながら、社内の標準的なデプロイフローに合わせたスクリプトを準備しました。
そうしてサービスは完成へ
この他にも、環境変数や認証周りの設定や、定期バッチの実行方法を調整したり、開発の終盤で社内の技術ルールが変更になって急遽対応したりと、様々な出来事がありましたが、無事にサービスをリリースすることができました。
この記事が、これからマイクロサービス開発に挑戦する方や、組織を横断したコミュニケーションに悩んでいる方の、何かのヒントになれば幸いです。
