Last one mile to Microservices

Last one mile to Microservices
Go Conference 2021 Autumn

Transcript

1. マイクロサービス移行を仕上げる Last one mile 2021/11/13 Kenta Moriwaki
2. 期待値調整 • マイクロサービスを使ったシステムで、モノリスで動いていたサー ビスの一部分を置き換えました • マイクロサービスへはこのように移行すべきだ、という発表ではな いです • Goの内部実装の話は少ないです:bow:
3. 今日話したいこと • Goを使ってマイクロサービスの運用を始めた、事例ベースの話です • 元となる設計思想や基本的なサービスはすでに存在していて、プロダ クションに出す手前あたりで自分はジョインしました • 本番運用するにあたり工夫した点や悩んだ点など共有したいです
4. 自己紹介 森脇健太 Retty株式会社 エンジニアリング部門 ソフトウェアエンジニア バックエンドとフロントエンド書いています 南インドやネパールのカレーが好きです
5. アジェンダ • 背景 • 本番導入に向けて必要なこと • こんなことがありました • まとめ
6. 背景 Rettyが提供している主なページ • 店舗ページ ◦ レストランの情報など • 店舗リストページ ◦ 検索結果など、店舗のリスト 店舗ページ 店舗リストページ
7. 背景 既存のサービスの問題 • ビジネスロジックが散らばった10年もののPHPシステム • 大規模なアクセスを支えるためのキャッシュが厚く、情報が反映され るタイミングが読めない • 過去に単一のサービスでバックエンドを作り直そうとしたが、重複し たロジックが残ったりして苦しかった前例があった マイクロサービスをベースとした、 リアーキテクチャが3年ほど前から進行中
8. 背景:リアーキテクチャへの道筋① モノリス → Adapterサービス → BFF → Frontendの形をまず用意
9. 背景:リアーキテクチャへの道筋② Adapterの主要一部(レストラン情報を返すサービス)を置き換える
10. 背景:リアーキテクチャへの道筋③ Adapterを少しずつ別のアプリケーションに置き換える
11. 今回の話のスコープ 途中まで進んでいたAdapterの置き換え作業 サービスからモノリスの依存を外し、本番に出した話です
12. 本番導入に向けて必要だったこと • モノリスからの脱却 • ログインユーザーのための認証基盤との連携 • 本番へのリリース方針を決める
13. 本番導入に向けて必要だったこと • モノリスからの脱却 • ログインユーザーのための認証基盤との連携 • 本番へのリリース方針を決める
14. モノリスからの脱却 サービスの分割単位は.protoファイルで定義 Adapterサービスは複数サービスを兼任していた
15. マイクロサービス多すぎ問題 Adapterから切り離すサービスが多いわりに..... • サービスそれぞれが小さい • 参照系の機能しか持たない ◦ 提供しているサービスの性質上、参照>>>更新 それぞれを別のインスタンスで動かすのはまだ早すぎるのでは?
16. miscellaneous(その他)サービス 小さな参照系のサービスをまとめる 別々のインスタンスで動かし、独立したデプロイの利点がまだない • チームごとに担当サービスがある、という組織構造ではなかった .protoファイルの存在により切り出しの粒度がわかっていた • 大きいサービスは独立、小さいものはmiscellaneousサービスに入れる といった判断が実装前に判断できた • サービスは他のサービスのコードに依存しないようにして、いつでも 分離できるようにした
17. サービスの全体図
18. サービスの全体図
19. 本番導入に向けて必要だったこと • モノリスからの脱却 • ログインユーザーのための認証基盤との連携 • 本番へのリリース方針を決める
20. 認証周りの話 ユーザーがログインしているかどうかでサービスが返す情報を分けたい ログイン情報を扱うセッションサービスはすでに存在し、モノリスから 利用していた
21. 認証周りの話 マイクロサービスを跨いでセッションを保持する主なパターン • 独立型 • 中央集権型 • 分散型 • ゲートウェイ分散型 中央集権型とゲートウェイ分散型の2択に絞られた マイクロサービス時代のセッション管理 https://engineer.retty.me/entry/2019/12/21/171549
22. 中央集権型 ユーザーの認証情報を 持ったセッションサービ スを、各サービスがそれ ぞれ問い合わせる • Revokeが簡単 • 可用性が必要
23. ゲートウェイ分散型 BFFのようなGatewayで セッションサービスを問 い合わせ、認証情報を JWTで受け取る 各サービスはJWTを受け 取り、各自で検証する
24. ゲートウェイ分散型 • 可用性が必要なのは 変わらず • 認証情報を使うたび にセッションサービ スを叩く必要がない ので負荷は減る 今後の負荷の可能性を考 えてこちらを採用するこ とに
25. 本番導入に向けて必要だったこと • モノリスからの脱却 • ログインユーザーのための認証基盤との連携 • 本番へのリリース方針を決める
26. どう本番に出していくか ミニマムな形で本番に出す 特定契約の店舗ページのみを切り替える ストラングラーパターンを使う • 特定店舗の場合はマイクロサービス 群を利用したシステムへ、それ以外 は既存のシステムへ、といった形で 振り分ける
27. モノリスか新しいサービスかを振り分けるサービス リクエストルーター(echoを使ったシンプルなシステム) 既存システム マイクロサービス群 を利用したシステム リクエストされたURLを もとに振り分け 10店舗 → 25店舗 → 100店舗…と徐々に広げながら負 荷に耐えうるかを見ていった
28. リクエストルーター リクエストされたURLパスを 正規表現でチェックして、新 しいサービスへと振り分ける • 該当のページのURL • それ特有のAPIのURL • フロントエンドで必要な URL(/_nuxt/ etc...)
29. 本番導入に向けて必要だったこと • モノリスからの脱却 • ログインユーザーのための認証基盤との連携 • 本番へのリリース方針を決める
30. 本番導入に向けて必要だったこと • モノリスからの脱却 • ログインユーザーのための認証基盤との連携 • 本番へのリリース方針を決める
31. こんなことがありました • ファイルディスクリプタの枯渇という落とし穴 • 対象店舗が更新されない
32. こんなことがありました • ファイルディスクリプタの枯渇という落とし穴 • 対象店舗が更新されない
33. ファイルディスクリプタの枯渇という落とし穴 本番に出して一ヶ月ほど経ち、その他サービスのうちの一つのエラー レートが上昇 socket: too many open files • ファイルディスクリプタが枯渇していた
34. ファイルディスクリプタの枯渇という落とし穴 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html
35. ファイルディスクリプタの枯渇という落とし穴 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html
36. ファイルディスクリプタの枯渇という落とし穴 Amazon ECSのデフォルトのリソース制限に引っかかっていた -> ulimitを増やして解決 一つのアプリケーションにサービスを詰め込んでいった結果、当初の想 定以上にDBアクセスが増えてしまっていた。
37. こんなことがありました • ファイルディスクリプタの枯渇という落とし穴 • 対象店舗が更新されない
38. 対象店舗が更新されない 振り分け対象の店舗はS3に格納し、リクエストルーターで定期的に取得
39. 対象店舗が更新されない
40. 対象店舗が更新されない 「*」デリファレンスされてる?? 新しい構造体なので、 tickerのチャネルを待ち受けて いるゴルーチンは存在してい ない......
42. 対象店舗が更新されない
43. まとめ 紆余曲折ありましたがマイクロサービスを本番に出して運用することが できています • 本番に出すことで初めてわかるようになる問題があるので、 実際に運用してみることは重要と再認識しました モノリスをマイクロサービスにする過程で、モジュラモノリスという選 択もしました • 状況によっては分割しない、という選択もありだと思います • その時々に合ったもので、必要なら他のものに変更しやすいアーキテ クチャを選んでいきたいです