2017/05/30(火) ~ 2017/06/02(金) の期間で,計4日間開催されていた AWS Summit Tokyo 2017 に参加してきた.僕は後半2日間に参加して,非常に満足度が高く,もっともっと AWS を使い倒さなきゃ!とモチベーションが上がった.セッションを聞くだけではなく,ブースで話を聞いてみたり,AWS 認定資格取得者専用ラウンジに行ってみたり,様々な楽しみ方ができたのも良かった.簡単にメモをまとめておこうと思う.
2017/06/01(木)
Speed matters - Amazon Kinesis が実現するストリーミングデータのリアルタイム分析
- 多くのデータは「持続的に」生成される
- 新しいデータほど,意思決定において価値が高い
- Kinesis
- Kinesis Streams
- Kinesis Analytics
- Kinesis Firehose
- 2ヶ月以内に東京リージョンで使えるようになる
- 細かく制御をするなら Kinesis Streams,フルマネージドに運用するなら Kinesis Firehose を使う
- シャードを複数回リードできるため,この点はキューと特性が異なる
split-shard
コマンド
Kinesis は全然使ったことがないので,話を聞いてきた.Firehose が東京リージョンで使えるようになる(やっと!)というのは期待できる.あと,途中で "Auto-Scaled Streams" という話があったはずだけど,詳細を聞き逃してしまったので,資料公開を待ちたいところ.あと Kinesis の事例として有名なスシローの話も出ていた.AWS をフル活用したアーキテクチャになっていて,これはクラウド導入を悩んでいる大企業にも刺さるなーと思った.
(資料公開待ち)
AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション
- AWS Edge Services
- CloudFront
- Shield
- Lambda@Edge
- CloudFront を静的コンテンツと動的コンテンツの両方の配信で使う
- エンドユーザーの近くを TLS の終端にする
- 1秒間の TTL も使えるため,短い時間のキャッシュでも,スパイク時の負荷を下げられる
- Lambda はリージョン内のイベントとして使うが,Lambda@Edge はエッジロケーションのイベントとして使える
- 訪問者バリデーション
- Bot 判定
- アクセスログの UserAgent 判定
- レスポンス生成
- HTTP Strict Transport Security (HSTS) でヘッダーを書き換えることもできる
- 訪問者バリデーション
- AWS Shield
- Standard Protection
- Advande protection
- 攻撃されたときにレポートを提供する
- 24時間体制でサポートをする
- 請求保護もする
- AWS WAF
- 特定の IP を一定時間をブロックすることができる
CloudFront 以外は使う機会がなく,特にエッジロケーションで軽量な処理が行える Lambda@Edge は,かなり未来な感じがするので気になる.
(資料公開待ち)
Cloud connect the world as a Glue
- SRE Team とは
- JP / US / UK 3拠点で一緒に会うことは難しい
- Hybrid & Multi Cloud な構成になっている
- JP : SAKURA
- US : AWS
- UK : GCP
- あえてフルマネージドサービスを使わずに,仮想サーバを使うことで,環境間の差異をなくしている
- グローバルなサービスを作るときは距離を意識する(超えられない壁)
AWS フル活用!という事例ではなかったし,他の勉強会でも似た話を聞いたことがあったため,新しい情報はあまりなかったけど,何度見てもメルカリの SRE Team は強いなという印象だった.
Startup CTO Night with Amazon CTO ~Werner Vogels による公開技術レビュー~
chikaku,Axelspace,Repro,3社の CTO がビジネス概要とアーキテクチャを発表し,Werner のレビューを受けるというイベントだった.聞いてる側としては非常に参考になったけど,レビューされる側は相当大変だ.「アップロード機能をセキュアにするために直接 S3 じゃなくて API を経由している」という話に対して「なぜ S3 ではダメなの?」とズバっと質問が出たときはちょっと背筋が凍った.全体を通して,アーキテクチャよりも,コスト計算を強く意識するべきというメッセージを感じ取ったし,そういう目線で経営に参画してこそ CTO なんだろうなとも感じた.
2017/06/02(金)
全部教えます!サーバレスアプリのアンチパターンとチューニング
- なぜ遅いのか?
- プログラムの問題
- コンピューティングリソースの不足
- コールドスタート
- アーキテクチャの問題
- 同時実行数
- コンピューティングリソースの不足
- メモリ設定はコンピューティングリソース全体の設定
- CPU バウンドな処理の場合は,メモリを増やす
- メモリ設定はコンピューティングリソース全体の設定
- コールドスタート
- VPC を利用する場合は,ENI を作成するため,10-30秒も掛かってしまう
- CloudWatch で取得できる Duration の値には,ENI の作成時間,コンテナ作成,ランタイム起動時間も含まれない
- 言い換えれば,課金対象にならないということ
- アーキテクチャの問題
- API Gateway を Kinesis のバックエンドとして API にすることもできる
- Lambda では RDBMS を使わずに DynamoDB などを使うと良い
- 同時実行数
- 平均実行時間とイベント数から,同時実行数が算出できる
- 上限緩和も可能だが,現在の最大値は 1000 なので,ほとんどの場合は到達しないのでは
以前にも似たようなスライドを見たことがあったが,改めて理解をし直すことができて良かった.会場も満席で,注目度の高さが感じられた.同時実行数の計算ロジックは初耳だったが,ちゃんとドキュメントには書かれていた.
今週発売になる「実践 AWS Lambda」は,ブースで先行購入することができた!毎日売り切れになっていたようなので,買えて良かった.積読せずに,最優先で読もうと思う.
実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~
- 作者: 西谷圭介
- 出版社/メーカー: マイナビ出版
- 発売日: 2017/06/09
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
(資料公開待ち)
Amazon EC2 Innovation at Scale
- Director of Product Management, EC2
- C4 ➔ C5
- C5 は Intel Skylake が乗っていて,そろそろ発表できそう
- R4 と X1
- R4 : GiB : cCPU = 8 : 1
- X1 : GiB : cCPU = 16 : 1
- 今年後半には 4TB の RAM を乗せた X1E を出す予定
- コスト最適化
- リザーブドインスタンス
- スタンダード
- コンバーティブル
- スポットインスタンス
- リザーブドインスタンス
- Amazon Lightsail
- 気軽に開発環境が欲しい場合
- AWS Summit Tokyo 2017 の初日に東京リージョンで使えることを発表した
EC2 のプロダクトマネージャーという仕事はかなり面白そうだと思った.去年の re:Invent のキーノートも見ていたし,リザーブドインスタンスとスポットインスタンスの話もある程度は理解していたため,あまり新しい情報は無かった.個人的に Amazon Lightsail を使う場面があるかどうかはわからないけど,東京リージョンで使えるようになったことは嬉しいことで,EC2 に敷居の高さを感じている人に使ってみて欲しいと思う.
(資料公開待ち)
Amazon EC2 Performance Deep Dive
- プロセッサ関連
- vCPU
- ハイパースレッドの論理コア
- ようするに,物理コアを仮想的に2個に分割する
- よって,物理コアを2倍すると vCPU になる
- ハイパースレッド無効化
- lscpu で CPU レイアウトを確認する
- 後半の論理 CPU をオフラインにする
- もしくは chcpu コマンドを使ったり,GRUB の maxcpu カーネルパラメータを設定することもできる
- P-state と C-state
- NUMA バランシングサポート
- vCPU
- ストレージ関連
- EBS 最適化
- st1 と sc1
- インスタンスストアを適材適所に使う
- ネットワーク関連
- 拡張ネットワーキング
- ENA カーネルドライバをインストールする
- プレイスメントグループ
- パフォーマンスクレジット
- CPU と EBS だけではなく,r4 インスタンスにはネットワークのクレジットがある
- ハードウェアアシスト仮想化 (HVM)
- 余計な仮想化のオーバヘッドを無くす
- なるべく HVM を使うことを推奨している
- RHEL6 の カーネルは 2.6.32 で,2009年に登場したものなので,新しくする
- チューニングをするときは,まず CPU から行うと良い
4日目で1番聞きたかったセッションに参加できた.プロセッサ関連の話は個人的に未知の領域で,実際に lscpu コマンドなどを試してみたりして勉強してみたいと思う.「詳解システムパフォーマンス」も買ったまま読めてないし,楽しみだ.ストレージとネットワークの話は,ある程度知っていた内容だったかな.困ったときにすぐインスタンスタイプを上げるのではなく,チューニングができるのかを考える癖を付けたい.
(資料公開待ち)
AWS マネージドサービスで実現する CI/CD パイプライン
- AWS Code 4兄弟
- CodeCommit
- CodeBuild
- CodeDeploy
- CodePipeline
- CodeStar
- BlackDay Gate
- デプロイしてはダメな日付の場合にデプロイを止める機能
- DynamoDB にレコードを入れておいて,合致する場合はデプロイを止める
個人的に Rails のデプロイ環境を作るなら GitHub + CircleCI (or Jenkins) + Capistrano のような構成にすることが多いし,実際に Code 4兄弟を使ったことがなく,セッションを聞いてみた.最近発表された CodeStar もどういうレイヤーの開発者が使うんだろう?という疑問がある.簡単に環境が作れることは良いことだけども.あと途中に話が出てた CloudWatch Events と Lambda を使ったシンセティックトラフィック(外形監視とは違う?)の AWS Reference Architecture は,調べても情報が見つけられなかった.詳細が気になるので,もしドキュメントがあれば読みたい.
(資料公開待ち)
その他
AWS 認定資格を取得している人だけが入れるラウンジがあって,そこで休憩などをしていた.早めに行ったこともあって,ピンバッチ以外に傘をもらうことができて,嬉しすぎた.雨の日にドヤ顔で使おうと思う.早い時間だと飲み物もお菓子も提供されてるんだけど,あっという間になくなってしまうので,もう少し定期的な補給があると良かったように思う.
今さら後悔しているのが AWS DevOps Challenge に参加しなかったことで,ああ,これは参加しておけば良かったなと残念な気持ちになっている.絶対楽しいし,学べるし,チームワークも大切だし,挑戦したかった.次回こそは!
まとめると,2日間非常に楽しめた!お疲れさまでした!