AWS Startup ブログ

保険 API サービスを支える justInCase のマイクロサービスアーキテクチャ【 Startup Architecture Of The Year 2019 ファイナリストによる寄稿シリーズ 】

皆さんこんにちは、スタートアップマーケティングの石渡です。

AWS Summit Tokyo で開催した Startup Architecture Of The Year 2019 では、7社のファイナリストによる熱いピッチコンテストが繰り広げられました。

このイベントは時間の関係もあり、各社5分という限られた時間でのピッチをお願いしました。当日は私も舞台袖から皆さんのピッチを聞いていましたが、ご登壇頂いた皆様の内容は、知恵と経験の詰まったもので、当日イベントに参加されなかった方にも是非お伝えしたいと思いました。そこで、ファイナリストの皆様に寄稿をお願いして、ここ AWS Startup Blog で、各社のアーキテクチャを熱く語って頂くことにいたしました。

今回は、justInCaseの小笠原さんにご登場頂きます。

こんにちは！justInCaseの小笠原です。

弊社ではエンタープライズのお客様が自社サービスにカンタンに保険を組み込むための保険APIを提供しています。

昨年末から今年春にかけて、保険APIのバックエンドの大規模リファクタリング（というか、新規構築）をしました。

Startup Architecture of The Yearのピッチではその効果についてお話したのですが、ブログではアーキテクチャのこだわりを解説させてください！

なお、ピッチ当日の資料はこちらです。

The Team-Changing Magic of Architecture

 

概要: ECSで構築したマイクロサービスアーキテクチャ

弊社では、保険契約や認証、プラン提案など、異なる責務のサービスをECS/Lambdaで提供しています。

認証に関しては一括で管理したかったので、前段にAPI Gatewayを置いて、そこでリクエストを検証しています。また、サービス同士の通信は全てCloudMap経由で行っています。

その他、AWSリソースの管理は基本的にCloudFormationで管理しています。

認証・認可を一括管理

以前（toC向け保険商品）のバックエンドではCognito UserPoolとAPI GatewayのIAM認証でリクエストの認可を管理していたので、ユーザー認証基盤に関してはCognitoを続投しました。

ただし、認可についてはIAM認証ではなくOAuthを利用するようにしました。

これは、社外のクライアントにAWS SDKを組み込んでもらうことなく、スムーズに保険APIに接続できるようにするためです。

 

スタートアップだと認証はWebアプリケーションフレームワークのライブラリで行うケースが多そうですが、このアーキテクチャは開発の素早さの面でも利点があります。それは、ローカルや自動テストで認証・認可をしないで済むことです。

ちなみに先日、VPCでのLambdaの実行時間が改善した、というニュースがありましたね。弊社のアーキテクチャは、その恩恵をものすごく受けていますよ！

 

マイクロサービスの相互呼び出しをCloudMap経由に限定

マイクロサービス同士の通信、例えばプランの提案サービスが契約サービスにプランの種類を問い合わせるときですが、CloudMapで提供されるホスト名を利用してアクセスしています。

以前のバックエンドでは、同様の状況ではECSのTaskを直接Invokeするような構成でした。この構成はビジネスロジックを追いかけづらい・ローカルでのデバッグがしづらい、といった問題がありました。それを受け、保険APIではホスト名経由の参照にしました。

この構成にしたことで、疎通確認もカンタンになりました。

これまでECSサービスが生きているかをチェックしたい場合、マネジメントコンソールでECSサービスのIPアドレスを調べてからcurlでリクエストをしていました。現在はいきなりホスト名でアクセスでき、心理的にも楽になったと思います。

 

CloudFormationをリポジトリで管理

個人的に一番こだわったポイントです笑

言うは易し行うは難しで、実際にはスタックごとのリソース配置の見直しが必要です。今回のバックエンドでは、以下の観点でCloudFormationのスタックを分割しました。

  1. 変更の頻度
  2. 依存性が一方通行になること

具体的には、VPC関連のスタック、ECRやNLBなどECS関連のスタック、API Gatewayのスタック、という感じです。

依存性を一方通行にしたことで、例えば新しい環境を作成する際にも、必要なマイクロサービスだけをデプロイできるようになりました。

ちなみにECSサービス自体はECS CLIで管理しています。ECSのデプロイ管理はいまだに何がベストか分かっていないので、もしご興味のある方がいればぜひディスカッションさせてください(笑)

 

まとめ

justInCaseでは保険をAPIとして提供するにあたり、認証とサービスの相互呼び出しの方法を統一し、インフラの管理を自動化しました。

もしこのアーキテクチャにご興味・ご意見がある方は、ぜひ@hiroga_ccまでメンションください！それから、弊社/保険APIにご興味がある方も大歓迎です。なんでもお尋ねください。

ここまで読んでいただいて、ありがとうございました！

小笠原さんによる寄稿は以上です。

【関連情報】

Startup Architecture Of The Yearでの小笠原さん登壇の様子（ログミー提供）