この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
概要
本レポートは2016年10月26日(水)〜28日(金)に開催されたServerlessConf Londonのセッション"Serverless architecture at iRobot"のレポートです。
本セッションのスピーカーはルンバでおなじみ iRobot で Cloud Robotics Research ScientistをしているBen Kehoeさんです。
発表資料
動画
スライド
iRobot 社について
- ユーザー買い切りのロボット
- ロボットはインターネットにつながっていて、その通信費は iRobot が支払う
- 運用費には非常にシビア
- 稼働しているロボットの数が大きいので、小さなコスト差が大きな差をうむ。
どうしてサーバーレスにしたの?
以前使っていた IoT プラットホームはスケーラビリティなどの点からAWSにインフラ移行した
移行については今年の re:invent で発表予定
コンタクトレイヤー
ロボットとアプリがクラウドと通信するために利用 通信には AWS IoT を採用
バックエンドレイヤー
Azure・オンプレなどの混在からAWS に移行
インフラ全般をAWS上で構築することになったので、制約なく設計できるグリーンフィールド開発だった。
なんでマイクロサービスにしたの?
モノリシックだったサービスは機能毎にデプロイするマイクロサービスに変わった
ではなぜマイクロサービスにしたのか?
- 理解しやすい
- 保守しやすい
- テストもし易い
- デプロイし易い
- チームが開発・運用のより広い範囲を見通せる
どういうアーキテクチャーなのか?
基本はサービス間はRCPで通信
gRPC など選択肢はいろいろあるし、AWSであれば API Gatewayといったサービスがある
トピック
- latency
- cost
- deployment
- discovery
- security
Latency/Cost
API Gateway を間に挟むと、サービス間の通信やコンテナ起動が増え、レイテンシーが増える その為、サービス(DynamoDB)を直接呼び出すようにした
関心の分離(separation of concern)の観点から、マイクロサービス毎にSDKを用意し、クライアントからはREST APIのようにシンプルに呼び出せるようにした。
一方で、通信先サービスのデータスキーマなどが発生すると、SDKもろともクライアントのコードを変更しないといけない。 HTTP APIサーバーのレイヤーがあれば、APIサーバーが吸収してくれる。
サービス間が密結合なのでマイクロサービスだけど、意図的にモノリシックぽくなっている。
Deployment
よく使われるデプロイ方法は以下の2種類がある
- インプレース : 稼働サービスのアプリを置き換える.エンドポイントは変わらない。 - Red/Black : ロードバランサーなどを使ってアプリを切り替える。エンドポイントが変わる
iRobot では Red/Black を全社的に採用している
Discovery
Red/Blackでエンドポイントが変わったときに、クライアント側はどのようにして対応するのか?
DNSでの切り替えは API Gatewayの機能制限によりできない。
サービスディスカバリに問い合わせる方式を採用
Security
API GWの前にCloudFrontをおいている
API GWもCloudFrontを使っているのでCloudFrontの2段重ね
メリット
- CloudFrontのオリジンサーバーとしてRed/BlackのAPI GWを簡単に切り替えられる
- CloudFrontはAWS WAFと連携できる
- CloudFrontで API GatewayのAPIキーヘッダーをつけ、APIキー認証させる。直接API Gatewayを叩け無いようにさせる
デメリット
- CloudFrontはリクエストを書き換えるため、AWS 認証を使って API Gateway と通信できない
Soapbox
テーマ
- Serverless as an identity
- Testing
- What's missing from providers
サーバーレスはバイナリー(0/1)ではない
- マネージドサービスを起動すれば、完全に手離れするものではない(バイナリー)
- プロビジョンド・スループットなど調整が必要(スペクトラム)
- BigQuery などはユーザーは管理から開放されており、サーバーレス度が高い
Unit Testing
- サービスとの通信のテストではモックを利用していない
- 実際のリクエスト内容を記録し、再実行するフレームワーク(placebo など)を利用している。
- テストの際にHTTPリクエストを実際に発生させずに、システム間の通信も含めたテストができる
Integration Testing
- 各マネージドサービスをモックしたプロダクトは機能に制限があり、機能制限によってテスタビリティが制限されるのは本末転倒のため、実際にデプロイしてテストしている。
- ただし、マネージド・サービスの障害をタイミングよく発生させる事はできない。
- SDKをいじってエラーをインジェクトしている
What's still missing?
- AWS Lambdaが利用するエンドポイント・認証情報などの設定を環境変数で制御できない
- サービス・ディスカバリ.問い合わせたクレデンシャルに応じてレスポンスを制御出来ると最高
- ハッシュ値によってLambda関数を識別。開発者が知りたいのはコードの中身。ハッシュ値からどういうプログラムなのか紐付けたい。
- デプロイ。API GatewayやLambdaにはローリングアップデートのようなデプロイの仕組みが備わっていない。
まとめ
- アーキテクチャー:マイクロサービス間にはAPI Gatewayは挟まないようにした。Pro/Conはいろいろあるので要件による
- セキュリティ： API Gatewayの前段にAWS CloudFrontを用意しAWS WAFやAPIキーなどセキュリティを強化した
- サーバーレスはスペクトラム
- 結合テストはモックではなく実際にサービスをデプロイしてテストする
7
