日本最大級の医療従事者専用サイト m3.com を運営するエムスリーのアンケートシステムのアーキテクチャーをご紹介 〜マイクロサービスの分割とアンケートデータのやりとり〜
https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d1-da-09
エムスリーでは医療従事者向けにアンケートを実施しています。アンケートと一口に言ってもやるべきことは多岐にわたり、配信や督促、アンケート回答画面、データ分析など、様々なステップを経てクライアントへその結果が届けられます。そして、それらを実現するシステムは、ステップごとに責務を分けたマイクロサービスとして構成しています。本セッションでは全体のアーキテクチャの説明に加えて、Cloud Pub/Sub を利用した依存関係の整理や、データベースの使い分けなどについて紹介します。
| 質問 |
回答 |
| マイクロサービスのような仕組みにすると、データの複製がある程度システム間にできてしまうと思いますが、データの不整合などの不具合は発生していないでしょうか？ |
インフラの障害（ネットワークエラーなど）で不整合が発生するケースは今の所ありませんが、同期ロジックのバグで不整合が発生するケースはありました。データはアンケート回答システムをメイン、他はそのコピーという位置づけで運用していて、不具合がある場合は同期ロジックの修正後、再同期という形で修正しています |
| Pub/Subを経由する場合のエラーハンドリングについてどのようにやっているか教えてください。 |
送信側はPublishできるところまで確認しています。受信側の処理が失敗した場合はACKを返さないことで、メッセージをPub/Subから再取得できるようにしています。 |
| Pub/Subを経由する場合、大量データを扱う際にデータの欠損、取りこぼし等は発生しないのでしょうか？ |
大量データはAPIのURLをデータとして受け渡すことで対処しています。取りこぼしについてはPub/Sub側のリトライにまかせています |
| ETLでデータを同期するバッチが動いていると思いますが、失敗したときにはどのようにリカバリしていますか？ |
基本的に日次で同期している処理と、毎時の処理の2種類を動かしています。毎時の処理は失敗しても許容していて、日次のものは失敗時に通知で問題にきづけるようになっています。また、日付を指定して再実行できるようになっています。 |
| アンケート定義・回答DBもSpannerを使用しているのですか？ |
アンケート定義・回答DBとしてはpostgreSQLを利用しています |
| 切り口 |
内容 |
| M3について |
|
| アンケートシステムのアーキテクチャ |
|
| システム構築時のポイント |
|
| GCPを利用した理由 |
効率よく情報を抽出できるようになった。コンパイル・起動が高速なのはサーバーレスな構成にするときにも大きなポイントになった。一般的なWEBサーバに近づけることができたので、ピーキーな使い方はしなくていい。 |
