AWS Summit Tokyo 2017に参加してきました
きっかけ
最近AWSを使ったサービスが多く、触れる機会も増えてきたので、今回初めてAWS Summit Tokyoに行ってみました。
開催日、5/30〜6/2日のうち、5/31は基調講演をライブストリーミングで視聴、6/2の午後は会場にいきました。
AWS Summit Tokyoとは?
ものすごい簡単にいうと、AWSに関する様々講演が聴けるカンファレンスです。 www.awssummit.tokyo
参加セッション
以下のセッションに参加しました。
初日の基調講演(ライブストリーミング)
サーバレスアプリのアンチパターンとチューニング
Amazon Innovation Dive Deep Session 2 〜Alexa〜
スマートホームシステムの開発 〜AWS を活用した新規サービスの立ち上げ〜
自販機 IoT 実現に向けた DyDo の取り組み
色々ありますが、本ブログでは「サーバレスアプリのアンチパターンとチューニング」についてメモレベルでまとめようと思います。
サーバレスアプリのアンチパターンとチューニング
対象者:サーバレスのWebアプリを作成している/しようとしている人
アンチパターンは以下の5個
プログラム
単純にロジックそのものの問題であり、コードの問題のことが多い。
各言語のベストプラクティスや最適化手法に乗っ取って作成すべき。コンピューティングのリソース不足
Lambdaは設定値がメモリの設定になっているが、実際にはCPUも関係している。
メモリに比例してCPUもアップしていく。
システムにとって最適なメモリを探すと良い。 ⇛ 「処理が変わらなくなる箇所」を探すコールドスタート
Lambdaの裏側では以下のような処理が行われている。
これら全てを実行することをコールドスタートという。
基本的に毎回同じ処理であるので、再利用し省略化できる ⇛ 「ウォームスタート」という
<Lambdaの裏側で行われている処理>
①ENIの作成
VPCを利用する時だけ、10~30sかかる。
CloudWatchのログには含まれない。
②コンテナの作成
③デプロイパッケージのロード
④デプロイパッケージの展開
⑤ランタイム起動・初期化
⑥関数/メソッドの実行
<コールドスタートが起こる原因>
再利用可能なコンテナが1つもない場合
利用可能な数以上に同時に処理すべきリクエストが来た場合
コード、設定を変更した場合
<コールドスタートを速くするためには?>
・コンピューティングリソースを増やす
・ランタイム(言語)を変える
言語によってコンパイルされるタイミングが違うので、意識すると良い
・VPCは必要ない限りは使用しないアーキテクチャの問題・同時実行数
同期よりも、非同期の方が良い。
Lambdaには同時実行数の制限があり、Invokeすると同時実行数に引っかかることがある。
APIGatewayなどと組み合わせるとこの問題が起きることもある。
⇛GETの場合はキャッシュを使うなど工夫が必要重要
「サーバーレスでも運用はなくならない」
「インフラ費用は必ずしも下がるとは限らない」
「監視もなくならない」 ⇛ Cloudwatchを設定して、メトリクスやカスタムメトリクスを使用、ログ出力とアラーム設定をするなどの工夫をすると良い
感想
今回初めて参加してみましたが、様々な導入事例やノウハウを聞くことができ、とても参考になりました。
基調講演ではAWSの歴史的なことを知ることもできたので良かったです。
来年もAWSに関わっていれば参加しようと思います!
(JAWSにも行ってみたい!)