JAWS DAYS 2018
＊ AWSコンテナサービスについて
コンテナを使うメリットは、起動が早いことやフィードバック早くできるという点です。また、コストも安く抑えることができます。コンテナを使うのに適しているのは、マイクロサービスや非同期の実行をする場合です。
CI/CDとして、開発環境でのテストからそのまま本番までもっていけることができます。
-
ECR（Elastic Container Registry）
Dockerコンテナレジストリで、イメージの保存や管理、デプロイを簡単に行うことができます。エンドポイントにアクセスできます。
GCPでいうGoogle Compute Engineの機能かと思います。 -
ECS（Elastic Container Service）
スケーラブルで高性能なDockerコンテナ管理サービスです。2015年に本番運用を支えるために開発されてGAされたのですが、最近利用が進んでいて大規模なスケール開発に利用されています。
IAMとのインテグレーションやVPCネットワークを、Task単位で実行することができます。
他サービスとの連携が簡単だったり、イベントドリブンな処理をできることも特徴のひとつです。
ちなみに、Task以外にServiceという概念があります。
-
Fargate（ファーゲート）
アプリケーションの開発に集中するために開発されたサービスで、基盤となるインフラストラクチャを管理することなく、コンテナをデプロイすることができるサービスです。
コマンド1つでコンテナを実行し本番環境へデプロイすることができます。
インスタンスの管理が不要で、タスクに割り当てたものだけ時間単位でコストがかかります。
ECSの機能をそのまま引き継いだ、フルマネージドのデータプレーンです。ECSと合わせて使うように設計されています。
CPUとメモリの組み合わせで課金され、組み合わせは約50パターンあります。
-
EC2（Elastic Compute Cloud）
必要な数の仮想サーバーを起動することができます。Fargateでは難しいGPUの選択などをすることができます。
-
FargateよりLambda使ったほうがいいケース
Lambdaはミリ秒単位まで指定できるので、粒度を細かく設定したいときや、イベントドリブンで実行したいとき、ランタイム管理したくないとき、分散バッチコンピュータを扱うときなどは、Lambdaを使ったほうが良いです。
-
EKS（Elastic Container Service for Kubernetes）
Kubernetes（クバネティス）をAWS上で簡単に実行できるようにするマネージドサービスです。
KubernetesとはOSSのコンテナ管理プラットフォームで、コンテナの大規模な運用に有用なサービスです。EC2の上でこのKubernetesを動かすことができるのですが、自分で管理するのは大変であるためEKSが登場しました。
Kubernetesのコントロールプレーンを簡単にしたものです。マネージドのエンドポイントに接続することができます。（マスターノードの部分）
ちなみに、EC2の管理は必要になります。
- DevOpsとは
Devは開発、Opsはモニタリングやアラートを行うことです。これを実現するために、コンテナが非常に有用です。
- サービスを選択する基準
Functionを使いたい/goやPythonを使う ：Lambda
Functionを使わない/コンテナ管理する ：ECS、EKS
Functionを使わない/コンテナ管理しない：Fargate
-
ECS API
タスク > サービス > クラスタ という概念があり、これをAPIに登録として登録することができます。また、スケジューリングの登録をすることができます。登録したAPIをDockerが起動させて使われます。
-
Terraform
インフラ構築や設定を、テンプレートファイルを使うことによって自動化するツールです。HashiCorpが作っています。
$ terraform applyで実行し、クラウド上にリソースが作成されます。
-
アーキテクチャ
github → CircleCI→ EC2
Slack → ECR
CloudWatchで監視（cwlogsコマンドを使うとログがみれます）
APIを使ったdatadogのメトリクス参照
＊ サーバーレスシステムへの移行
オンプレ → クラウド → サーバーレス へ移行したユーザー企業さんの実例のご紹介でした。- S3
インターネット用のストレージサービスで、ファイルシステムとして利用できます。ただ、ファイル移動で失敗するとこあるため、全部移動して残ってたら再実行するといった考慮が必要です。ファイル名にハッシュ値入れるとアクセス効率が良くなったそうです。
-
SQS（Simple Queue Service）
完全マネージド型のメッセージキューイングサービスです。
実行保証してくれるのですが、意図せずに複数実行される場合あります。また、順番は保証されません。pub/subモデルとしてSQSを使っているそうです。
（pub：イベントを起こす、sub：イベント処理を行う）
-
Lambda
イベントドリブンでコードを簡単に実行できるサービスです。実行時間が最大5分までという制限があり、DynamoDBに書き込めない場合もあるため、同時起動数の制御などを考慮する必要があります。
-
DynamoDB
完全マネージド型のNoSQLデータベースサービスです。
結果生合成の設定をすることがありますが、キャパシティーの制限があるので、制限を超えると書込ができません。
-
Cloud9
ブラウザのみでコードを記述、実行、デバッグできるクラウドベースの統合開発環境 （IDE）です。ターミナルやデバッガーが付いている他、不可欠なパッケージがインストールされているため、素早く開発を行うことができます。
-
CloudFormation
インスタンスやVPC環境を何度も作成する手間を省くため、定義ファイルを作成して自動的に環境を作成してくれるサービスです。これを使うことで、CircleCIでCIをすることはできるのですが、Lambdaの同時実行数は制御できません。
＊ 実践Serverless x Microservices
マイクロサービスにすることでリリースを早くするといったメリットがあります。マイクロサービスにするにあたって、DDDを実践してサービスやドメイン単位の分割、関心ごとでの分離をしました。（EC2周りで1サービス、Lambda周りで1サービス、1つのサービスから1つのDBを参照など）
DDDの考え方については、「現場で役立つシステム設計の原則」などが非常に役に立ったそうです。
http://gihyo.jp/book/2017/978-4-7741-9087-7
メッセージングにはSQS・SNSを使用し、LambdaとLambdaの間やEC2の間に挟むアーキテクチャにしているそうです。
-
Kinesis
大規模なストリーミングデータをリアルタイムで処理する完全マネージド型サービスで、SQSと同じような機能なのですが、SQSよりも低コスト・シーケンス番号が振られているのでデータの重複がない・スケーラビリティが備わっているといった特徴があります。
また、複数のLambdaを起動することができますが、その分コストは高くなります。ここで注意なのが、1秒間に5こまでしかポーリングできないので、Lambdaを30個など起動する場合は遅くなってしまいます。そのため、Step FunctionsをLambdaとLambdaの間におくことで解決しました。（順序は保証されません）
この解決をしても度々エラーになることがあり、自分でタイムアウトをするようにしているそうです。
-
ログについて
マイクロサービスにすることでログが散らばるため、入り口から出口まで同じIDにする、必ず同じ場所にログを出すなどトレーサビリティを考慮する必要があります。
-
設計について
レジエンス（回復力）を意識する必要があり、障害が発生したら切り離して自分で立ち上がるような設計にします。デプロイは多くなります。マイクロサービスの間にSQSを置くことが多いです。（今回はKinesisを使っているそうです）
-
X-RAY
クラウドアプリケーションを構成するコンポーネントとサービスを監視するサービスです。処理の流れが他のサービスと異なり、DynamoDBのスパイクに対するオートスケールが間に合わないといった問題がありました。
＊ Terraformについて
コードのパッケージ構成としては、moduleディレクトリ配下にステージングとかでフォルダを分け、その下にmain/output/input /lambda/iam などでtfファイル分けているそうです。Terraformを使うとbootstrapの環境は10分で構築できます。
Slackに通知することも可能です。
＊ Lambdaを使った負荷試験について
超短期的なアクセスがきたとき、ジェネレーター使って負荷試験をする方法がよく使われていますが、攻撃サーバーの稼働率悪かったりといったデメリットがあります。そのため、API Gatewayを使って1発でできるサーバーレス攻撃ツールを作成したそうです。Step Functionsビルダーを作成し、Lambdaのセットで攻撃します。攻撃が全て終わったら、Slackに通知させるようにしているそうです。
注意としては、実行後にゴミが残ってしまうので、別のLambdaでDelete Queueを呼んでゴミを消す必要があります。
動的にLambdaを呼ぶことができ、ログ以外何も残りません。
- 注意
ファイルディスクリプタの上限メモリは1024で、実行時にメモリサイズ変えれません。
ステートマシンを構築するためのjson容量は1MBまでです。
自分自信のステートマシンは削除できません。（そのため別LambdaでQueueを削除させるようにしています）
コンソールで開くと死にます。
＊ 感想
最近はGCPを使っているのでAWSから少し離れていましたが、GCPに共通するアーキテクチャのお話も多かったため、非常に勉強になりました。また、レシーバーを貸し出していて、チャンネルをセッションによって合わせて聞くようになっていたので、話が聴きやすかったです。（特別なセッションは英語を同時翻訳してくれていました）
英語でのセッションもいくつかあったのですが、資料が見やすかったので英語が苦手な私でも意味を理解することができました。
初めてこのイベントに参加しましたが、他社や海外の事例がきけて大変良い経験になりました。