はえーすっごい。

下記 connpass の視聴メモをざっくりまとめたものです。
https://m3-engineer.connpass.com/event/187265/

タイトルの通りオンプレ=>クラウド移行に関するお話でした。
移行自体の知見というより、クラウドリソースの運用ルールなど、仕組みを整えるうえで
大変だったことや工夫した点について聴ければいいなというモチベーションでした。
特に権限管理周り。

※ 個人的にまとめたものなので、内容に不備がある場合はコメントして頂けると幸いですm

0. エムスリーについて

「インターネットというメディアを活用し、医療の世界を変革します。」
2000 年創業
- 1996 Yahoo Japan
- 1997 楽天
- 1998 サイバーエージェント
- 1999 DeNA
- と振り返ると改めて歴史を感じる。
20年間増収・増益
コロナ下の社会に対しても強いスタンスを持って臨んでいる
- アクセス数の増加
- 医師/製薬マーケから、インターネット経由の情報収集ニーズの高まり
- インターネット企業時価総額 No.1 (4.33兆円)
エンジニアの組織構成
- エンジニア 90 人, プロダクトごとのチーム 16 チームほど
  - めちゃくちゃ個人の裁量ありそう
- 「技術選定は原則チームの自由」

1. 大規模クラウド移行の背景

移行に踏み切った要因

ポジティブな要因
- さらなる事業拡大のため。
ネガティブな要因
- 諸事情が重なり、どうしようもなくなったから。

起こってしまった諸事情 (2019. 8)

SRE チームメンバー 5 名のうち 2 名の退職申し出
- インフラ作業全般を SRE に任せていたのでヤバイとなった。
- オンプレSREがなかなか採用できない。
慢性的なハードウェアの負債
- 積み読ならぬ積みサーバの増加
  - セットアップなどの運用も SRE の仕事
- オンプレ機器の故障が結構あった。

移行に関わるターニングポイント

Algolia Solultion Engineer の方
- 『事業のコア技術としてオンプレが必要なら必要、そうでなければ不要』
- オンプレに拘らず、その分野が得意な人( AWS とか )に任せてしまうフルクラウドへの機運が高まる。
sansan CTO 藤倉さん
- 『フルクラウドに移行する際、経営陣の説明が必要になる。その際、事業拡大を支える開発スピードこそ強み。』
マネジメントチームによる逆転の発想
- 「クラウド化をネタにSREを大量採用できるのでは？」

=> やっていき

移行に関わる希望

2009 から SOA を導入していて、多くのサービスがマイクロサービス化されていた。
- Release It を愛読していた前CTO の功績の一つだとか。
いくつかのチームが、独自にクラウド技術の知見が溜まっている状態だった。
- 研究開発的なことをやっていたらしい。
チームごとに必要な技術を採用できる文化的な基盤が揃っていた
- いざとなればキャッチアップがサクッとできる(というか好きな)文化、ということっぽい。

そして、諸事情の発覚から2ヶ月後の 2019. 10 にクラウド移行宣言!!

2. 移行後のネットワーク設計について

全体のサービス環境

300 microservices
30 VPCs
オンプレ + AWS + GCP

移行時に起こり得るカオス

属人化による管理不能化
構成要素の依存関係が不透明になる
VPC間のセキュリティリスク
スケールしない ( => 後からの入れ替えが簡単ではない) 技術設計に起因する事業成長への足かせ
- IPレンジとか

カオスを防ぐ技術的アプローチ

マネージドなルーター技術の採用 ( to 3 )
- AWS Transit Gateway
terraform によるリソースのコード管理 ( to 1, 2 )
- 1つのパラメータの値から関連リソースのパラメータを計算するなどして、同じ情報や相関性のある値を2回書かないようにしている。
- ただし「技術選定は原則チームの自由」のため強制ではない。
VPC, subnet, ACL設計の標準化 ( to 3, 4 )
- 「技術選定は原則チームの自由」とはいえ、VPC, subnet, ACL レベルで構成を変えたいニーズは実際無い。
- 仕組みを設けることで、全チームに自由に選ばせるための理解をしてもらうコストを減らした形。
private IP レンジ割り当ての設計・体系の構築 ( to 4 )
- 二分木的に CIDR レンジを切っている。
構成図の整備・書籍化 ( to 1, 2, 3, 4)
- 以上のアプローチを「どうやったか」はコードから読み取れるが、「なぜそうしたのか」までは汲み取れない。
- そこをプラスしたものをテックブックに載せている。
- インフラは寿命の長いリソースのため、書籍化にも向いている。

3. "止められないサービス" のクラウド移行

止められないサービスの例

サイトの認証基盤
100 ほどの認証 API

認証基盤のサービス構成

( 他サービス -> ) LB -> web サーバ -> AP サーバ -> DB サーバ

移行の流れ

予定
- 難易度の低い順に、AP サーバ -> DB サーバ -> web サーバ / LB をそれぞれ移行させていく。
実際
- オンプレの LB の性能限界?により、AP サーバ / web サーバ / LB -> DB サーバと順番を変更。

発生したトラブル

SSL 証明書が切り替わり、キャッシュ関係でエラー。
個別に名前解決するクライアントや AP サーバに直接アクセスするアカウントなど個別の対応が必要なパターンが生じた。
DB のフェイルオーバーによるマスタ昇格とコネクションプールの機能がかち合って、コネクションの切り替えがうまくいかなかった。

freee でも最近起こった DNS 障害と同じような現象が起こっていたっぽい。

4. 質疑応答

AWS について、アカウント分割についての戦略はありますか？
- チームに対応した vpc の割り当てを行っているまでで、チームごとのアカウント分割はしていない。
- セキュリティ基盤などは別アカウントで運用。
BIT VALLEY 2020では山口さんからterraformからaws cdkへの移行の話が出ていましたが、terraformとの使い分けなどされているのでしょうか？
- 技術選定はチームで自由なので、全チーム terraform をつかえ！と言うポリシーはない
移行時のテスト体制やテスト中のチェックシート、テストにかかった時間など可能な範囲で教えていただけますか？
- 明確に計測はしていないが、半分以上チェックにかかった印象。
- 移行の周知や他チームとの連携、QAに機能の担保 / エンジニアバックエンドの担保など実作業以外の工数が目立っていたよう。
awsリソースの権限管理(IAM, AWS account など)の仕組みについて、特に気をつけた点があれば聞きたいです。
- 権限管理というかインフラリソースをどう運用するかもチームで自由っぽい。
- 1 チーム 1 SRE (一人) 体勢
  - admin 権限を付与して、チームのインフラ構成をお任せ
  - 9割以上のチームが実施
  - 一部チーム(認証基盤とか)は階層的な感じ
チーム(プロダクト)横断での開発が必要なった場合、チーム間での terraform 利用の有無の差は問題になりますでしょうか？
- IaC (Infrastructure as Code) 使ってないチームがほぼない。
- 一定のキャッチアップは必要だが、プロダクト自体のキャッチアップの方が割合が多め
- AI チームとか共同開発多めなやつだと、キャッチアップ用の Doc が充実している
- OSS 的にチーム横断な開発体制が整っているので、問題になっている感じはなさそう。

感想

SRE チームメンバー 5 名のうち 2 名の退職申し出

何があったんだ... (質問すればヨカタ)

(インフラ)構成図の整備・書籍化

アプローチを「どうやったか」はコードから読み取れるが、「なぜそうしたのか」までは汲み取れない。

これは面白そうだと思った！
実際に書くとなるとキャッチアップやばそうだけど、歴史的背景とかも含めて書籍に残すのは
後々の振り返りに使えそう。

「技術選定は原則チームの自由」

1 チーム 1 SRE (一人) 体勢

チームの自由度の高さにとても驚いたし、ただ回しているだけじゃなくてめちゃくちゃデカい成果を出してるから、
エンジニア一人ひとりの裁量の大きさがちゃんと活かされているんだなぁと思った。
少数精鋭の集まりって印象が強かった...

メモを書き起こしてみて、「あ、ここ質問すればよかった...」てポイントがたくさんあって反省。
なんとな〜く聴いちゃってるのもったいない...
話聴くこと自体も大事だけど、自分が興味のある部分に特にフォーカスできるようになりたいなぁ