AWS re:Invent2015参加レポ（3）

サーバーサイドエンジニアの田中です。ずっとソーシャルゲームやってましたが最近動画系に異動になりました。

re:Invent2015に参加してきましたが、自分が参加したセッションの中ではAPI GateWay / LambdaといったAWSサービスを使ったマイクロサービス、サーバーレスに関するセッションが多かったかなと思いますので、そのあたりをピックアップして書いていきたいと思います。

ちょうどAPI Gatewayの東京リージョンでの利用開始やLambdaの新機能発表もこのタイミングであり、Scheduled Eventなど嬉しい機能もあって、おお！と思ったのを覚えています。

参加セッション

The Serverless Company Using AWS Lambda / AWS Lambdaを使用しているサーバーのない企業(YouTube/SlideShare)

• インスタンス -> コンテナ -> サーバーレスへの流れ
  
  • アプリケーションコード以外は気にしたくない
  
  
• AWS Lambda
  
  • イベントドリブンでサーバーインスタンス不要
    
  • スケールはAWSが自動で行う
    
  • イベントによる従量課金（実行されない間は課金されない）
  
  
• データプロセスアーキテクチャ
  
  • with Servers
    
    • データ・ソース（S3, Dynamo, SNS,,,）の変更を監視
      
    • 変更をキャッチしworkerに処理させるためにキューイング
      
    • wokerが後続処理を実行（アプリケーションコード部分）
      
    • その他、Load Balance、CrossAZ、AutoScaleなどの考慮も必要
      
  
  
  • without Servers
    
    • アプリケーションコードのみ（Lambda）
      
    • データソースのListening/polling、キューイング、Load Balance、AutoScaleなどはLambdaが実施
  
  
• PlayOn!による事例
  
  • 高校スポーツをストリーミング配信するサービス
    
  • EC2（Wowza）など多数のAWSサービスをベースにしたアーキテクチャを、Lambdaを中心とするアーキテクチャに変更
    
  • 異なる解像度のTrancecode処理、サムネイル作成、QOS解析などをそれぞれ行うLambda Functionをカスケードさせて使用している
    
    • 新しい機能が必要になったら新たなLambda Functionをカスケードに追加するだけ
  
  
• リアルタイムデータプロセッシング アーキテクチャパターン例
  
  • File Processing Workflow
    
    • S3 -> Lambda -> S3/DynamoDB
      
    • S3へのファイルアップロードをトリガーとし、加工をしてS3にファイルを戻したりDynamoDBにデータを保存など
      
  
  
  • Stream Processing Workflow
    
    • Kinesis -> Lambda -> Redshift / SNS
      
  
  
  • DB Triggers Workflow
    
    • DynamoDB -> Lambda -> DynamoDB / Redshift
      
    • Dynamoへのデータ更新をトリガーに分析用にRedshiftに流すなど
      
  
  
  • CRUD Backend Workflow (API Gataway)
    
    • API Gateway -> Lambda -> S3 / DynamoDB
      
  
  
  • その他のトリガー
    
    • Echo Skills
      
    • Lambda Scheduled Events
      
    • IoT Actions
      
    • Cognito Sync Triggers
      
    • CloudFormation Custom Resources
      
    • SES Actions
      
    • SWF Tasks
      

Using Amazon API Gateway with AWS Lambda to Build Secure and Scalable APIs / Amazon API GatewayとAWS Lambdaを使ったセキュアでスケーラブルなAPIの構築(YouTube/SlideShare)

• Key takeaways
  
  • API Gateway + Lambda でのフルマネージド構成。スケールも自動
    
  • IAMによるアクセス制御
    
  • SwaggerによるAPI定義サポート（Swagger Importer）
    


• AWS サービスの活用例
  
  • Lambda: ビジネスロジックの実行
    
  • Cognito: temporary AWS credentials発行による認証
    
  • DynamoDB: データストア
    


• pet store アーキテクチャ（sample）
  
  • Cognitoを利用したログインAPI
    
  • IAM roleによるアクセス制御
    

From Monolithic to Microservices: Evolving Architecture Patterns in the Cloud / モノシリックからマイクロサービスへ：クラウドで進化するアーキテクチャ(YouTube/SlideShare)

• GILT（ファッション系のECサービスみたいです）のアーキテクチャ変遷
  
  • 初期（2007年）
    
    • Rails/Postgres/memcached/job worker
      
  • 2011年
    
    • モノリシックなJavaアプリケーションの投入
      
    • ビジネスラインごとのチーム構成
      
  • 2015年
    
    • Play/Scalaによるマイクロサービス化
      
    • 約156のマイクロサービス
      


• 1サービス当たりの構成
  
  • container(docker)
    
  • JSON/HTTP endpoint
    
  • フレームワーク,、モニタリング、ロギング
    
  • アプリケーションコード
    
  • データストア


• サービス間連携
  
  • ZooKeeperでのendpoint lookup
    
  • ELB -> 利用サービスへのRESTfull call
    


• 組織構成
  
  • モノリシック
    
    • UI / App / DBA など技術面でのチーム構成
  
  
  • マイクロサービス
    
    • ビジネスごとのチーム構成（チームごとにUI / APP / DBA）
      
    • 技術選定、開発、品質、デプロイ、サポート
      


• サービス利用者/提供者の考慮点
  
  • サービス利用者
    
    • エラー制御
      
    • 適切なリトライ処理などで、提供者側に負荷をかけない
      
    • キャッシング
  
  
  • サービス提供者
    
    • メトリクス送信
      
    • 実装を意識させない
      
    • 後方互換
      
  
  
  • API Gatewayの活用
    
    • スロットリング（トラフィック制御）
      
    • キャッシング
      
    • モニタリング
      
    • バージョニング
      
    • アクセス制御
      


• データマネジメント
  
  • DBはサービス単位（共用しない）
    
    • どのdata storeを使うかの選定もサービス単位
      
    • スキーマ変更の影響も少ない
      
  
  
  • トランザクション管理
    
    • pessimistic model
      
      • 利用者側での制御
        
      • トランザクションマネージャ活用
        
      • そもそもトランザクション管理が必要にならないような設計
        
    
    
    • optimistic model
      
      • 結果整合性の許容
        
      • 冪等性担保の上でのリトライ
        

最後に

マイクロサービス化に向けて、サービス分割の粒度であったりデプロイ/テストなどの運用方法、管理方法などなど検討する部分も多く、ノウハウをためていく必要はあると思います。 いきなりの既存サービスの置き換えはハードルが高いかもしれませんが、新規サービスなどで検証込みで小さく初めていくにあたり、JAWSなどのフレームワークも出始めていることもあり、API Gateway / Lambdaの活用は十分に検討する価値があるのではないかと感じました。 LambdaがVPCサポート（今年後半利用可能予定のようです）すれば更に活用方法は広がるのではないでしょうか。

初の海外カンファレンス参加で英語力の低さに愕然としましたが、現地での熱的なものも感じられベタにモチベーション上がって帰ってきました。

おまけ

ラスベガスから帰ると、だいたい「（カジノの結果は）どうでした！？」みたいに聞かれます。個人的にカジノはそんなに興味なかったのであまりやってないと答えると、「あー...（つまんねー奴だなぁ）」、「そうなんだ...（空気読めよなぁ）」、「なるほどですね～（この田舎者が）」みたいな空気になりました。

次行く機会があれば、嘘でも「いやー、ボロ負けして飯も食えないっすわー wwww」って答えようと思います。何かのご参考になれば幸いです。