あけましておめでとうございます。今日から02/05までの平日にエムスリーのSREでブログリレーを開催します。その初日の投稿を担当させていただくエムスリーエンジニアリンググループの岩佐です。グループリーダーという立場でSREチーム、基盤チーム、セキュリティチーム、Unit4(m3.com/サイトプロモ)を担当しています。
私からはエムスリーでSREを拡大しようと推進している経緯/流れについて一筆認めさせていただこうかと思います。
要約、早速だけど
- SREを短期的に大量に採用するのは不可能、じゃないかのう？
- オンプレミス環境で拡大していくサービス群をSREチームのみが運用していくのは難しい。こんなん困難では？はー、どうしよう
- 権限の移譲、DevOpsの推進をするのがよさそう、以上。まだ続くけど
- そのためにクラウド移行していこうという段階
- SREの採用戦略も変更
最後に持ってきて『ようやく要約です』もありでした。
経緯、メンバーに敬意を、チームに契機を
私が入社したのは2015/04と6年弱前です。その時から比べてもユーザー数、サービス数、サービス単体の機能、色々な観点でm3.comは拡大しています。 それに伴い開発チームの数も増え、エンジニアの数としても倍以上に増えています。現状の組織構成は以下に示す図の通りです。
SREチームは本取り組みが始まった2019/07時点では4人、現執筆時点(2021/01)では私含めて7人です。 上記の図にあるSREチーム以外の15チームが開発しているサービス群をSREチームが一手に担い運用していくスタイルはSREメンバーに大きな負荷がかかっていました。組織全体としてもアプリケーションエンジニアの増加に比してSREチームの増員は少なく、うまくスケールアップしにくい状況に陥っていました。
この時点より更に少し遡った過去(2018/06)の出来事ですが、SREチームはインフラチームというチームが改名して成立したチームです。エムスリーでは設立当初(2000/09)からデータセンターでハードウェアを運用するオンプレミスにてサービスを運用していました。それらを管理するのがSREチームのメインタスクでしたので、インフラエンジニアが採用ターゲットでした。昨今インフラエンジニアの採用は非常に難しくなっていまして、そこが増員がうまくいっていない原因でした。
他にも歴史的経緯やリソース利用の効率化のために複数チーム/サービスで同一インスタンスを共有するなどいくつかの問題点がありましたので、前述のものも含めて列挙します。
- インフラエンジニアの採用問題
- オンプレミスリソースの維持/リプレイス
- スケールアウトのための需要予測/ハードウェア調達の困難さ
- サービス/チームのインフラコストの不透明さ
- SREチームへの権限一極集中
- DevOpsが推進しづらい
- アプリケーションエンジニア/SREの比率
- スケールアップ/スケールアウトに伴う困難
- ロードバランサー共有による負荷集中
- DBインスタンス共有による負荷集中
- KVMの同一ホスト上でのリソース奪い合い(いくつかのリソースにおいてオーバーコミットしていた)
これらの問題点を解決したいということが本取り組みの始まりでした。 また、その他にも2019年末から2020年始にかけての出来事ですが、当時のチームリーダーの退職、最古参のメンバーの退職、交代したチームリーダーの退職というイベントがありました。その後にチームリーダーとしてチームに入ったため、SREチーム自体の立て直しというのも急務でした。
方針、状況に合わせて更新
経緯で示したような問題点にどうやって対処していくべきでしょうか？
エムスリーではアプリケーションチーム側にすべてを任せていく方向で考えました。つまり、権限の移譲とDevOpsの推進です。
幸いにもマイクロサービス化が進んでいたため、サービス単位で権限の移譲や稼働環境の移動などはやりやすくなっています。オンプレミスのままハードウェアごとアプリケーションチームに渡してしまうというのは流石にチーム側の負担が大きいため、比較的扱いやすいであろうAWSをはじめとしたクラウドに稼働環境を移動し、その上で権限を移譲し、管理を任せていくことにしました。
移行戦略ですが、AWSの6R(ref: “The 6 R’s”: 6 Application Migration Strategies - AWS Migration Whitepaper )
- Rehost(Lift and Shift)
- Replatform
- Repurchase
- Refactor/Re-architect
- Retire
- Retain
をそれぞれ検討しました。それぞれに良い点悪い点はありますが、エムスリーの状況を考えるとReplatform, Re-architectを中心に据えることにしました。Rehostを選択した場合、インフラ部分がきれいに整理/コード化されないままクラウド化されることになります。そのままアプリケーションチームに渡した場合、チーム側の負担が非常に大きく、それのサポートのためにSREの協力が必要ということで、今抱えている問題点に対しては旨味がなさそうでした。幸いにもそれら問題点はすぐに対処しないと即破綻するというものではなく、徐々にでも改善を進めれば多少の猶予はありそうでした。今回は「権限の移譲とDevOpsの推進」を目指していますので、アプリケーションチーム側が無理なく運用できることを主眼とします。そのために一定の手直しを行い、AWSが用意してくれているサービスを活用し、インフラ部分をきっちりとコード化した上で3年を目処にクラウド移行を計画していくことにしました。
そして、これらをチーム内にて推進および今後管理/運用していく役割を持つエンジニアをチーム内SREとして任命していくことにしました。サービス運用に携わるメンバー(SREチームのメンバー+アプリケーションチーム内SRE)は現執筆時点(2021/01)で実に40名を超える数と取り組み前から比べると実に10倍以上にも拡大することができました。経験の差やスキルの違いから多少の混乱やトラブルも起きましたが、運用/監視/サービスレベルの改善などがチーム主導で活発的に進むようにもなってきています。また、採用においても少しインフラ触ったことがあるアプリケーションエンジニアや、インフラ未経験だけどSREに挑戦してみたいという人を受け入れることが可能になったということも大きいです。自分で環境を構築する部分から携われるため、理解を深めながら実運用に入っていけています。
計画、そして軽快に改革
以上のように大きな方針は決まりましたので、具体的にクラウド移行と権限の移譲をどのような順番で進めていくかの計画を立てました。最初は全チームでは取り組まず、まずはいくつかのチームで試行することとしました。オンプレミスのサーバ群はansibleで管理されていました。ansibleは1つのレポジトリで管理されていたのを、アプリケーションチーム単位に切り出してコードの共有と対象サーバへの権限を付与していきました。それと並行してチーム側ではチームで管理しているサービスをどのような順番でクラウドに移行していくかの計画を立てました。下図はその計画に利用した移行順評価用のマトリクスです。基盤チームとUnit4というチームで合同で進める際に利用したものです。
縦軸は工数、横軸はリスクです。この図において右上のものから順番に実施することとしました。移行順決定の理由は
- 工数小
- 小さくてもとりあえず実績を出していくことが大事！
- メンバーに成功体験を得てもらいたい
- 「そんなに時間かけて何も変わらないならやめたら？」と批判されないように
- リスク小
- 新しい取り組みなので、経験を重ねてから複雑なシステムにとりかかりたい
- 初っ端で事故を起こして、「クラウドは危険だからやめよう！」みたいな流れにならないように
などからです。実際にリスクや工数を考える上で検討時に利用した項目は
- クラウド化難易度
- ユーザーが外部から直接アクセスするサービスかどうか
- アプリ(言語/フレームワーク/Docker/Ansible, …)
- データストア(種類/バージョン, …)
- httpサーバ
- cron/バッチ処理
- 参照する外部サービス
- API提供先サービス
- ログ関連
などです。実際に移行する場合にはサービス一式を一緒にAWSに持っていくのではなく、LB/webサーバ、APサーバ、DBサーバなど部品ごとに持っていったりもしました。分割して移行した理由は前述の問題点にあったロードバランサーの負荷集中緩和のためだったり、その他状況に応じてよりよいやり方を模索した結果です。また、移行順も決定しましたが、ある程度慣れた段階で難易度の高いものにも挑戦しようと柔軟に変更しました。m3.comは医療従事者向けのサイトであり、コロナ禍で需要が増加したため、クラウド化のメリットであるスケールアップ/スケールアウトのメリットを早く享受したかったからです。
その後、移行したAWSアカウントの管理をアプリケーションチーム側に完全に移譲し、運用/監視もチーム側で回せるようになりました。最近ではUnit4(m3.com/サイトプロモ)というチームで、サービスの数値を追っているプロモーション担当者やニュースの記事を書いているような編集者も巻き込んで、SLO/SLIを定義しサイトを改善していくという活動にも着手し始めています。一時的に監視や障害対応のレベルが下がるといった混乱も起きはしましたが、全体としてはよりよい方向に進んでいると実感しました。
本取り組みは前述の通りに初期はいくつかのチームでだけ実施しました。十分に成果が確認でき、方針として概ねよかったことが確認できたので、最近は全チームで実施するようになっています。現執筆時点では2021年度中には大半のサービスがクラウドに移行するように計画を立てています。
「ピンチはチャンス」と言ってしまうのは好きではないのですが、現在抱えているおよび今後起きそうな課題を整理し、それに真正面から取り組んで解決を目指すということ自体はよかったと思っていますし、それを成し遂げるのがエンジニアなのでしょうと再認識しました。協力していただいたチームメンバーに尊敬と感謝の意を伝えたいと思います。
まとめ、ちょっとまともに
- エムスリーは権限の移譲とDevOpsの推進を目的としてクラウド化をすすめています
- 現場任せではなく、組織で意思決定して一丸となって進捗させています
- 計画通りには進まないけど、勝ち筋を見つけるためにしっかりと計画すべき
- 一緒にクラウド化をすすめ、エンジニアリングを楽しむ仲間を募集中です
明日(2021/01/13)以降もエムスリーのSRE中心に情報を発信していく予定ですので、よろしくお願いいたします。
We are hiring.
