(レポート)[ServerlessConf London] 「 Serverless architecture at iRobot」 #serverlessconf

概要

本レポートは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キーなどセキュリティを強化した
• サーバーレスはスペクトラム
• 結合テストはモックではなく実際にサービスをデプロイしてテストする

関連リンク

• iRobot Case Study - Amazon Web Services
• iRobot Scaling Connected Product Business on Amazon Web Services - Jul 13, 2016
• re:invent 2016 "IOT401 - Serverless IoT Back Ends"