マイクロサービスの導入で起きがちな課題とその具体的な対処法

マイクロサービスの導入で 起きがちな課題と その具体的な対処法 @icchy_san 1

イントロダクション 自己紹介 伊藤 友一 @icchy_san ● ● ● ● © HireRoo, Inc. 株式会社ハイヤールー共同創業者の一人 インフラやバックエンドをメインにしつつ、フロントエンドの修行を しています 前職では某エンジニアQ&Aサイトや看護・介護職の方向けのサービス のインフラを触っていました 最近はLeetCodeと友達になってます 2

Agenda 1 マイクロサービスで陥りがちな課題の紹介 2 ハイヤールーにおける対策 3 まとめ ※本スライド内におけるMSはマイクロサービスを指す。

01 マイクロサービスで陥りがちな課題の紹介

マイクロサービスで陥りがちな課題の紹介 陥りがちな課題 1 分散したリポジトリ（ポリレポ）管理 2 ログのトレーシングが難しい 3 MS初心者による設計の破壊 © HireRoo, Inc. 5

マイクロサービスで陥りがちな課題の紹介 陥りがちな課題 課題１：分散したリポジトリ（ポリレポ）管理 ● ● ● ● 各リポジトリごとに担当者が分かれることで、独自で発展し、 基盤に変更が必要な場合に大規模な変更や、変更に対応できる 人が属人化してしまう 自分が管理しているMS以外の変更を追うのが難しい MSの初期開発者が知らない変更が入っていることもある 複数のリポジトリをクローンする必要がある ※ポリレポとは、モノレポの反対でMSごとにリポジトリを用意する方法 © HireRoo, Inc. 6

マイクロサービスで陥りがちな課題の紹介 陥りがちな課題 1 分散したリポジトリ（ポリレポ）管理 2 ログのトレーシングが難しい 3 MS初心者による設計の破壊 © HireRoo, Inc. 7

マイクロサービスで陥りがちな課題の紹介 陥りがちな課題 課題２：ログのトレーシングが難しい ● Microservice Aでエラーを返した場合以下の2パターン存在 ○ Microservice A自体がエラーになっているケース ○ Microservice Aではなく依存しているMSがエラーを返しており、大本のMicroservice Aがエラーになっているケース ● ログから遡るとAを見てから順を追って依存しているMSのログを見に行く必要があり、緊 急度の高いエラーが発生した場合に致命的になる可能性がある © HireRoo, Inc. 8

マイクロサービスで陥りがちな課題の紹介 陥りがちな課題 1 分散したリポジトリ（ポリレポ）管理 2 ログのトレーシングが難しい 3 MS初心者による設計の破壊 © HireRoo, Inc. 9

マイクロサービスで陥りがちな課題の紹介 陥りがちな課題 課題３：MS初心者による設計の破壊 ● データをMS間で同期するために循環参照を生んでしまう ○ ○ 循環参照を許容してしまうと、デプロイ時にどちらを先に出すべきか迷子になる 循環参照が起こる原因 ■ 企業情報を扱うCompanyサービスと契約しているプラン情報を扱うPaymentサービス を例に見ると下図のような依存関係となる。 ■ Comapnyサービスは企業情報を取得する際にプラン情報を持つPaymentサービスの データを取得して返す。Paymentサービスが直接Companyの情報を更新しようとした 場合に循環参照状態に陥る。 © HireRoo, Inc. 10

02 ハイヤールーにおける対策

ハイヤールーにおける対策 陥りがちな課題 1 分散したリポジトリ（ポリレポ）管理 2 ログのトレーシングが難しい 3 MS初心者による設計の破壊 © HireRoo, Inc. 12

ハイヤールーにおける対策 課題１： 分散したリポジトリ対策 ポリレポからモノレポへの変遷 モノレポ: 1つのリポジトリで複数のプロジェクトを管理する方法のこと。 © HireRoo, Inc. 13

ハイヤールーにおける対策 課題１： 分散したリポジトリ対策 ポリレポ時のMS初期化 MSで新規開発する際に必要なこととしては次の通り 1. 2. 3. Protobufファイルの定義 アプリケーションコードの実装 terraformの定義＆実行 以上の3つのことを既存サービスの実装のコピーと名前の変更で行う © HireRoo, Inc. 14

ハイヤールーにおける対策 課題１： 分散したリポジトリ対策 具体的に僕らが直面した課題 その際にあった課題は以下の通り： 1. 2. 不要なファイルも共にコピペされるためファイルの取捨選択をしなければならない 変更漏れによるバグの発生とその対応 以上により初期化に少なからず時間がかかっていた © HireRoo, Inc. 15

ハイヤールーにおける対策 課題１： 分散したリポジトリ対策 初期化スクリプトの作成 初期化時にコピペ後に名前の変更を行うことで発生する問題 を緩和するために初期化スクリプトを作成 ポリレポで管理されているものはアプリケーションコードのみであるため、対象をアプリ ケーションコードに絞り、初期化用リポジトリを作成 手順としては以下の通り 1. 初期化用のスクリプトを持ったリポジトリをクローン 2. ローカルマシン上でスクリプトを実行→アプリケーションコードの初期化完了 a. protoのインターフェースの実装のみに集中できる © HireRoo, Inc. 16

ハイヤールーにおける対策 課題１： 分散したリポジトリ対策 モノレポ化 解決したこと ● ● ● 変更の透明度が上がり変更の検知が容易に可能 MSのコードもGitHubのCodeOwners設定によりレ ビュワーの指定とレビュー必須の成約をディレク トリごとに可能 インフラも含め全てのファイルが集約されたこと で、見通しがよくなり変更の追跡が容易に可能 一方で課題も… ● CIの複雑化 ○ 例：MS_Aでのみ必要なCIの処理が他のMS にも影響する © HireRoo, Inc. ● ● HireRoo インフラ基盤をCloud RunからKubernetesへ移行しモノレポで管理し始めた話 モノレポでマイクロサービスを開発するため 戦略と運用 17

• https://hireroo.io/journal/tech/migrate-cloud-run-to-kubernetes-and-mono-repository#index_AzGieDKI
• https://hireroo.io/journal/tech/mono-repo-for-microservices

マイクロサービスで陥りがちな課題の紹介 陥りがちな課題（再掲） 課題１：分散したリポジトリ（ポリリポ）管理 ● ● ● ● 各リポジトリごとに担当者が分かれることで、独自で発展し、 基盤に変更が必要な場合に大規模な変更や、変更に対応できる 人が属人化してしまう 自分が管理しているMS以外の変更を追うのが難しい MSの初期開発者が知らない変更が入っていることもある 複数のリポジトリをクローンする必要がある ※ポリレポとは、モノレポの反対でMSごとにリポジトリを用意する方法 © HireRoo, Inc. 18

ハイヤールーにおける対策 課題１： 分散したリポジトリ対策 モノレポ化 解決したこと ● ● ● 変更の透明度が上がり変更の検知が容易に可能 MSのコードもGitHubのCodeOwnersによりレビュ ワーの指定とレビュー必須の成約をディレクトリ ごとに設定可能 インフラも含め全てのファイルが集約されたこと で、見通しがよくなり変更の追跡が容易に可能 一方で新たな課題も… ● CIの複雑化 ○ 例：MS_Aでのみ必要なCIの処理が他のMS にも影響する © HireRoo, Inc. ● ● HireRoo インフラ基盤をCloud RunからKubernetesへ移行しモノレポで管理し始めた話 モノレポでマイクロサービスを開発するため 戦略と運用 19

• https://hireroo.io/journal/tech/migrate-cloud-run-to-kubernetes-and-mono-repository#index_AzGieDKI
• https://hireroo.io/journal/tech/mono-repo-for-microservices

ハイヤールーにおける対策 課題１： 分散したリポジトリ対策 モノレポ化 モノレポ化したことでインフラ周りのコードも含め1つのリポジトリに集約 されたため、初期化時の対象コードが増え、対象は以下の通り。 ● ● ● ● ● アプリケーションコード Hooksファイル（CIで利用するサービス独自の処理が定義されている） kubernetesで利用するファイル gPRCのprotoファイル terraformファイル インフラ周りの設定ファイルに関しては設定を誤ると事故が起こるため、このタイミングで初期化スクリ プトの拡張を行い、全てを自動で初期化するように変更 必要なファイルがほとんど自動生成されるためコピペや不要なコードの削除がなくなり、初期 化にかかる時間を削減 © HireRoo, Inc. 20

ハイヤールーにおける対策 課題１： まとめ ● マイクロサービスは基本的に同じコードが多く生み出されるので コピペしてバグを含むよりは手間はかかるが、初期化スクリプトなどの工夫が効果的 ● ポリリポ時に抱えていた課題はモノレポに移行することで解決されたが、 一方で移行時には、ポリリポ時にはなかった新たな課題の対策が必要であった ● 一度構築してしまえば、以降使い回しにより開発の効率化を見込める © HireRoo, Inc. 21

ハイヤールーにおける対策 陥りがちな課題 1 分散したリポジトリ（ポリリポ）管理 2 ログのトレーシングが難しい 3 MS初心者による設計の破壊 © HireRoo, Inc. 22

ハイヤールーにおける対策 課題２：ログのトレーシングへの対策 トレーシング対応のモチベーション ● ● 一連のリクエストに紐づく処理のうち失敗した箇所の把握が容易になる ログだけではわからないパフォーマンスの課題を見つけることが容易になる ○ 処理時間の内訳を可視化 ○ レイテンシーの可視化 © HireRoo, Inc. パフォーマンス 課題発見 例 タイムラインビュー例 23

ハイヤールーにおける対策 課題２：ログのトレーシングへの対策 TraceIDをリクエストに埋め込む ● ● リクエストに一意のTrace用のIDを渡し、一連のリクエストでIDを共有しログに 埋め込みを行った Trace用のIDを利用することでDatadogのAPM > Tracesにより下図のようなタイ ムラインビューで原因となるMSの特定を即行うことができる 24 © HireRoo, Inc. 開発環境用 エラー例

ハイヤールーにおける対策 課題２：ログのトレーシングへの対策 過去のエラー調査方法との比較 1. 2. 3. エラー通知確認 どこでエラーが発生しているのか確認 原因の特定 過去 現在 エラー発生源の確認Step1 エラー発生源の確認Step2 エラー発生源の確認＆特定 Stepが1つに エラー発生源の特定 © HireRoo, Inc. 25

ハイヤールーにおける対策 課題２： まとめ ● トレーシングの導入によりエラーの原因特定や、エラーにこそなっていないがパフォーマンスに不 安がある処理を予め発見することができる ● ちょっとした一手間（トレースIDの追加）のみでメリットを享受できる。 © HireRoo, Inc. 26

ハイヤールーにおける対策 陥りがちな課題 1 分散したリポジトリ（ポリリポ）管理 2 ログのトレーシングが難しい 3 MS初心者による設計の破壊 © HireRoo, Inc. 27

ハイヤールーにおける対策 課題３： MS初心者による設計の破壊対策 現状 ● 現状は主に経験者によるレビューやエデュケーションでカバーしている 今後 ● ● 変更対象のMSがどのMSから参照されているか可視化をすることで事前にチェックが できる 今後は依存関係チェックをCIのジョブに組み込み、 事前に循環参照を検知し、実装者にフィードバックする仕組みを構築する ○ すでに稼働しているMS同士の依存グラフはDatadogによって可視化されているが… ■ 構築前に知る必要がある ■ 自動でレビュー前に弾きたい を満たすためには不十分 © HireRoo, Inc. 28

03 まとめ

Take Away 全体のまとめ ● MSを運用するためには初期コストがかかる（ハイヤールーの取り組み） ○ 新規MSを作成するたびに発生するミスを減らすために初期化スクリプトの作成 ○ 一連のリクエストで同一のIDを埋め込むことでトレーシングを容易化 ○ （これから）MS間の依存検知によるMS初心者による破壊の回避＆レビュー時のコスト削減 ● ただ一度構築してしまえば、以降使い回しにより開発の効率化を見込める ● ハイヤールーにまだまだ改善の余地があるのでぜひ一緒に改善していきませんか？ © HireRoo, Inc. 30

ご清聴ありがとうございました 31