# マイクロサービス化の実践・推進と、それを一緒に進めるチームのリードをしていました。
- マイクロサービス化チーム作りでは、一緒に進めるチームメンバー4人全員がマイクロサービス化の推進をリードできる存在になることが必要でした。
- マイクロサービス化の実践については、巨大なモノリシックなサービスを小さいサービス群に分割するための実現可能な方法を見出す必要がありました。
- マイクロサービス化の推進では、システム開発部のメンバーに必要性を理解してもらい協力してもらえる状態にすることが必要でした。
## マイクロサービス化チーム作り
- チームメンバーが皆同じところを目指せるようにする必要があると考えました。
- そのためにまず、ゴールとそれに向かう手法について、また、なんのためにそれをするのかについて、認識を揃えました。
- 当初はメンバーができることがそれぞれ違いましたが、全員がマイクロサービス化に必要な技術を身につける必要があると考えました。
- そのために最初は各々ができるタスクを担当してもらいつつ、並行してマイクロサービス化に必要なスキルマップを作り、次第にタスクをこなしながら必要なスキルを習得してもらえるようなアサインに変えていきました。
## マイクロサービス化の実践
- 当初、部長の考える手法がありましたが、複数サービスのまずはバッチだけを切り離すという無理が生じる方法でした。
- そのため、サービス丸ごとをひとつずつ切り離していく方法が良いことを提案して進めました。
- 巨大モノリシックなシステムからサービスを切り離していきますが、データベースも切り離そうとすると、システム停止を伴わなくてはなりませんでした。ユーザからお金を頂戴して24時間サービス提供しているシステムのため、頻繁にシステム停止をすることができません。
- そこで、段階的に独立化をすることにし、まずはデータベースだけは共有したままで、他の部分は全て切り離されている状態を目指すことにしました。この状態を「ほぼ独立化」と呼称することにしました。
- 新しいサービスを作る際は、始めから「独立化」または「ほぼ独立化」して開発する必要がありましたが、システム開発部のメンバーは、サーバ構築依頼をし、Rails.newして必要な設定を入れ、デプロイ設定をするなどの経験をしたことがない人がほとんどでした。
- プラットフォーム部と共に、サーバ構築依頼をする際のテンプレートを作成し、必要なスペックやミドルウェアなど抜け漏れないように依頼できる仕組みを作りました。
- Rails.newした後に誰でも必要な設定を入れられるよう手順書を作成しました。のちに、技術部の人が質問に答えると必要な設定が入るgemにしてくれました。
- デプロイタスクも一部をgem化し、簡単にデプロイ設定ができるようにしました。
- ロジックが高凝集・疎結合な状態であればサービスとして切り出せるのですが、巨大モノリシックなシステムの中はロジックが一箇所にまとまっておらず影響範囲も広い状態でした。定数に至っては、影響範囲がシステム全体にまで及んでいました。しかしながら、頻繁に改修が発生するサービスについてはコンフリクトする可能性があるため、マイクロサービス化チームが直接手を加えることはできません。
マイクロサービス化チームで手が出せないものはシステム開発部で改修を進めていく中で、少しずつ高凝集・疎結合な状態に近づけてもらう必要がありました。
- 現行の巨大モノリシックなシステムではどこにロジックを設置しても影響範囲が広くなってしまう欠点がありました。それを防ぐため、そこに置くだけでスコープが狭くなるディレクトリをいくつか設置し、高凝集・疎結合となる考え方と共に伝え、システム開発部に活用してもらえるようにしました。
- 定数についてはymlファイルを読み込んでincludeしたクラス内で扱えるようにするためのgemを作成しました。スコープを最小限に狭めることができた上に、gemに暗号の複合化機能も備えたため認証情報なども管理できるようになりました。ymlにrubyのコードを書いておけば読み込まれた時にerbで変換される機能も備えたおかげで実用性が高く、今でもシステム開発部の定数定義のスタンダードとして利用されています。
## マイクロサービス化の推進
- システム開発部は人数が多く(50名以上)全員に足並み揃えてマイクロサービス化を考慮して開発してもらうことが困難でした
- 全員にマイクロサービス化のメリットと必要性を伝えた上で、具体的な手法は各チームリーダに伝え、開発業務の中でチームリーダがメンバーに少しずつマイクロサービス化のための技術を伝えてもらう方法をとりました。
- マイクロサービス化、高凝集・疎結合へのリファクタリングなどを進めている一方で、また新たに密結合なサービスが作られてしまう懸念がありました。
- 定期的にチームリーダにヒアリングを行い、少し先に予定されている案件で初めから独立サービスとして作った方が良いものや、開発の中でリファクタリングできそうなものがないか、このような場合どうすれば良いかなど、相談する機会を設けました。
最後までお読みいただきありがとうございました。