Going Serverless with AWS(AWS Summit Tokyo 2017)を聞いてきました

Tweet

AWS Summit Tokyo 2017でセッション「Going Serverless with AWS」を聞いてきましたのでレポートというか記録です。

聞き間違えているところとかあればご指摘いただけると幸いです。

StepFunctionsは触り始めていたのですが、SAMはこのセッションではじめて聞きまして、これは使わないとな、と。

既存の処理をそのままの単位でサーバーレスにしてもあまり恩恵もなく、もしかしたらタイムアウトに引っかかる可能性もあり。
最小単位までマイクロサービス化して疎結合にすることで、修正時の影響を極端に減らし、スケールをやりやすくする、運用や保守がなくなるわけではない。

「減るもの(OS,ミドルウェア)」よりも「増えるもの(分散化、スケール、スピード)」に対してのメリットに着目して選択するべきと思いました。

以下メモです。

サーバレスとは？

• サーバについて考えることなくアプリケーションをデプロイして実行すること
• よりモジュール化されたアプリケーション開発に移行している、マイクロサービス化
• 差別化がどこで、ではなく、何をするかになってきた
• サーバの管理や保守を取り除くだけのものではない
• アイドリングにお金を払う必要がない
  *　日経は画像加工をLambdaですることで10分の1までコストを下げた
• リクエスト数に応じて分散化される
• Lambda,S3,DynamoDB,API Gateway,,,,,,,,
• 運用の複雑を解消
• 開発者の生産性向上
• 価値のスピード化、差別化
• 静的、動的webサイト、Flask , Expressのためのパッケージ
• チャットボット、Echo用Alexa Skill

サーバレスアプリケーション

• 既存アプリの分解
• コンポーネント群の通信
• サービス境界の明確化
• Step Functions パラレル、シリアルにアクテビティを実行

ベストプラクティス

• S3,DynamoDB,ElastiCacheでステートの外部化
• SAMテンプレートとして関数をエクスポート
• AWS CodePipeline + SAM
• AWS CodeStar
• Dead Letter Queues
• AWS X-Ray

Canonの取り組み

課題

• レイヤ間の複雑性が増し、密結合化
• レイヤ間のコミュニケーションコストが増加
• テストの増大化
• スピード感も低下

Conwayの法則

• 連携不可
• 組織のあり方がシステムに反映する
• チームがレイヤーごとに分かれていく

MicroServicesの推進

• レイヤーが横方向に肥大化するのを縦に分割することで防ぐ
• シンプルな構成を保ちつつ分割する

データベースも分割する

• ドメイン駆動設計(DDD)モデリング

注意点

• Restful , DDDの視点で設計する
• デプロイ自動化
• 密結合しないように疎結合する

メリット

• コード量、テスト工数、開発工数、運用、など様々な工数を削減できた
• 組織、システムの硬直化、密結合を防げた

最後までお読みいただきましてありがとうございました！

【PR】 「AWS認定試験対策 AWS クラウドプラクティショナー」という本を書きました。

【PR】 「AWSではじめるLinux入門ガイド」という本を書きました。

【PR】 「ポケットスタディ AWS認定 デベロッパーアソシエイト」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター3年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。