AWS Summit 2019に行ってきました

はじめに

AWS Summit 2019に行ってきました。
3日間開催されるのですが、私は2日目の6/13のみ参加です。
発表資料はまだ公開されていないので、自分がメモした内容を残しておきます。しかし資料と合わせてみる前提のメモなのでわかり辛い・・・。資料が出たら修正します。

twitterのリンク：#awssummit

参加セッション１：サーバーレスのエンタープライズへの拡大とベストプラクティス

資料は日本語だけど発表は英語のセッションでした。

サーバレスとは
・インフラプロビジョニングや管理不要
・価値に対して支払
・自動的にスケール
・高可用性、セキュア

サーバレスによって
・アジリティの向上
・運用工数の軽減
・・・

典型的なユースケース
・Webアプリ
・バックエンド
・データ処理
・チャットボット
・Alexa
・ITオートメーション

よくある懸念
・開発メンバーをどうやって育てる？
・正しいレベルのガバナンスの設定
・セキュリティコントロール
・ロギング／モニタリングをどうやるか？
・パフォーマンス計測

高速開発のポイント
・IaC
・都度アプリとインフラのテスト
・ビルド、デプロイプロセスの自動化

AWS SAM：AWS Serverless Application Model
https://aws.amazon.com/jp/blogs/news/aws-serverless-application-model-sam-command-line-interface-build-test-and-debug-serverless-apps-locally/

ローカル開発ツール
・AWS Step Function
・・・

CI/CDツール
AWS SAMや3rdパーティーFW
Serverless Framework, Zappa, Apex, Begin
・・・

コードに対するガバナンス
デリバリパイプライン内でのコードチェックの強制執行

モニタリング、トラブルシューティング
AWS X-Ray

参加セッション２：AWSにおけるデータベースの設計指針

昔はDBと言えばリレーショナルDBだったが、2000年頃のインターネットの普及により、アクセス数が増えた。それにより、これまでとは異なる新しい要件が出てきた。
新要件を満たすために、NoSQL(Not only SQL)が出てきた。
RDBもNoSQLもそれ単体ですべての問題を解決するものではなく、適材適所(Purpose Build)、組合せながら使っていくもの。
どうやって選ぶのか？
・リレーショナルデータベース
・KVS
・ドキュメントデータベース
・インメモリデータベース
・グラフデータベース
・時系列データベース
・台帳データベース

AWSのデータベースサービスはマネージドサービス。運用・管理に関わるところはAWSが自動で行ってくれるため、DBAとしてはスキーマデザイン、クエリ作成、クエリ最適化だけに注力することができる。

リレーショナルDB

言わずと知れた昔ながらのDB。AWSではAmazon RDSというサービスがある。

NoSQL

KVS(Key Value Store)

KeyとValueでデータを管理。
- 拡張性に優れる
- 高速でデータの読み書きが可能
- 分散処理に適している
- トランザクション処理できないものが多い
AWSではDynamoDBというサービスがある。

Document DB

JSONやXMLなど、不定型なデータ構造に対応する。
AWSではAmazon Document DBというサービスがある。一般的にはMongoDBが有名で、Amazon Document DBはMongoDBと互換性がある。

インメモリデータベース

高速なKVS。データをメモリ上で処理することにより高速な処理ができる。AWSではAmazon ElastiCacheというサービスがある。（私はずっとElasticCacheと勘違いしていました・・・）

グラフデータベース

関連を管理するのに適切なデータベース。SNSなどにおけるフォローとかフォロアーのイメージ。複雑に相互に関連し合っている。AWSではAmazon Neptuneというサービスがある。

時系列データベース

株とか温度とか、時々刻々と変化していくデータを管理する。変化を追う。AWSではAmazon Timestreamというサービスがあるが、今プレビューの状態。今後仕様が変わるかもしれない。

台帳データベース

変更や削除ができない（させない）、イミュータブルなDB。変更されると困るものを変更させない。ブロックチェーンなどで使用されているもの。AWSではAmazon Quantum Ledger Database(QLDB)というものがある

まとめ

これらのDBをどう組み合わせるかがポイント。適材適所。

参加セッション３：Amazon EC2の進化の歴史から学ぶEC2入門 2019年版

EC2基礎知識

EC2：Elastic Computing Cloud
ハイパーバイザの上に置いたゲストOSのことをインスタンスと言っている。

AMI：Amazon Machine Image
AMIからEC2を起動。VPCの中にインスタンスが立つ。

EC2の歴史

ここから歴史の話。
・2006年8月：EC2発表

顧客の要望に応える形で様々なインスタンスタイプを提供してきた。

EC2サービスに対する顧客要望	要望を受けて新たに提供したインスタンスタイプ
CPUもGiBも少なすぎる	M1
WebサーバーとしてはCPUコア数が多い方が良い	C1
メモリを多めに積んだものが欲しい（データベースとか）	M2

　⇒3個のファミリーが出来上がった

調査してわかったこと：
・殆どのEC2インスタンスにおいて、実はCPUが回っていない時間がかなり多い。低負荷なアプリケーションが多いということがわかった。
　⇒低負荷用で安いものとしてT1のサービスを開始した。
T1のTはTinyのこと。
・一方で、CPU 使用率100%という状況が多い顧客もいた。高速な科学技術計算とか、並列計算に使用されていた。
　⇒CC1(Cluster Compute)のサービスの開始。そこからさらに、GPUを搭載したCG1、当時最先端のIntelの～～：CC2という高性能インスタンスも登場した。

EC2は顧客の声を聞いて進化してきた。
・M1よりももう少しCPU性能を上げたM2。
・ストレージ容量に特化したインスタンス。

VDI：リモートデスクトップ

2012-13年で今とほとんど変わらないファミリーが揃った。
ただスペックを上げるのではなく、（インテルの進化に合わせて）最新世代のインテルを積んだものを搭載してきた。
レイテンシを短くしたい：SPIOB
HVM
KUM：ハードウェアのハイパーバイザー化
CPUに合わせて世代を変えて新しいインスタンスをリリースしてきた。

ネットワーク関連の進化

ネットワーク帯域の増加
C3：2013年頃
C5n：今2019年
　⇒帯域もだいぶ増えてきた。

ネットワークレイテンシ
C3→C5n+EFA
　⇒だいぶレイテンシを減らした。
帯域が増えただけでなく、レイテンシも少なくなってきている。

仮想化のオーバーヘッドをいかに減らすか

ハードウェア化で対応してきた。
XENからNitroに書き換え。
ハードウェア化でCPUのオーバーヘッドを少なくした。

ベアメタルインスタンス
仮想化なしに丸々そのインスタンスを使ってもらう。
NitroでHW化することで実現できた。
　⇒VM Ware Cloud on AWS に繋がった。

AWS Graviton Process
AWS独自のプロセッサ

CPUインスタンスの変遷
2016年頃から機械学習、ディープラーニングが盛んになってきた。
　⇒P2サービスの登場。G2だと遅いという要望に応えたもの。

P3dn：V100搭載
G4dn：仮想化　T4
NBIでG4が出るというアナウンスがあった。

機能編

・2006年まではCentOSだったが、商用で使いたいという要望が出てきた。
・2007年RedHat版をリリース
・2009年管理しにくさを改善
　　⇒マネージメントコンソールの登場
2009年頃に管理機能を追加して管理しやすくなった。
2009年1月当時のコンソール
EC2しかなかった（スライド左上）
スライド左下 Elastic IPsとか、今でも使う機能は2009年当時からあった。
・2010年9月：Amazon Linux 公開
・2011年3月：東京リージョン解説　4番目のリージョン

まとめ

どういう背景で機能ができたのかを押さえておくと、自分に必要な機能かどうかの1つの判断基準になる。
- 性能
- 運用・管理
- 価格

参加セッション４：Amazon EC2 インスタンスタイプの選び方

c5d.xlarge
↑これはEC2のインスタンスタイプ。
このセッションでこれの見方がわかるようになる。

今、旧世代も含めると200ぐらいのインスタンスタイプがある。

ラインナップを知る

最近ではベアメタルサーバという仮想サーバでないものもある。
物理サーバ(Host Server)
AZは北米の方が2割ぐらい安い。電気代とか配置できるサーバの大きさとかの関係。東京以外のAZを考えてみてください。

Graviton：ARMのアーキテクチャ

FPGA：自分でプログラムしてカスタマイズできる半導体素子。
GPU, FPGA：自分で買うと高い。クラウドなら、使ってみて気に入らなかったら捨てることができる。

後から追加（アタッチ）できるアクセラレータ

ネーミングから全容を理解する

c5d.xlarge
c：インスタンスファミリ
d：インスタンス世代
5：（追加機能）
xlarge：高速コンピューティング(GPU, FPGA)

・インスタンスファミリ
5つのカテゴリ
- 汎用
- コンピューティング最適化
- ストレージ最適化
- メモリ最適化
- 高速コンピューティング(GPU, FPGA)

・M60：グラフィックベースが得意
・GPU：機械学習
・Zld：最大4GHz

・EC2インスタンス世代
世代が進むにつれて大きくなる。なるべく新世代を使いましょう。

・EC2インスタンスの追加機能
- d：標準インスタンスに対して内臓ストレージ（インスタンスストア）付加
- n：標準インスタンスに対してネットワークを強化
- a：AMDのCPU
- e, s：その他　従来よりCPU, メモリ搭載量が異なる。

・EC2インスタンスストア
サイズは固定で選べない。インスタンスタイプで決まる。インスタンスを停止するとデータが消える。

・EC2インスタンスサイズ
以下で分類
- CPU
- メモリ
- ネットワークキャパシティ

・サイズのネーミング
nano→micro→small→・・・
毎にネーミングも変わる。
リソースが倍になると費用も比例して増えていく。

・バースト性能
常に表記された性能があるわけではない。裏でクレジットというものを持っていて、それに基づいて1日何時間は表記の性能を維持するというもの。

その他補足情報

特殊なインスタンスタイプ

EC2ベアメタル
ハイパーバイザを廃止。
⇒HWとして直接使いたい場合に使用する。
仮想化していると遅いのでは？AWSでは工夫しているので差はない。EC2ベアメタルの目的はそこではない。

T2, T3バースト可能パフォーマンスインスタンス

CPUもバーストして使えるものがある。それがT2, T3。
Webサーバとか、アクセスがあった時は性能を出して、そうでない時は性能は必要ない。負荷に応じてバーストする。
CPUクレジットという考え方。普段は貯金をしていて、負荷があると貯金を使っていくイメージ。
クレジットを使うとバーストできない。
CloudWatchでクレジットを確認できる。
最近はUnlimitedもある。

64 bit ARMアーキテクチャ AIインスタンス

AWSが作ったCPU
自分たちで作ったものなので単価が安い。
ちょっとテストで動かすときなどに便利。

インスタンスの起動上限と制限緩和

インスタンス毎に起動できるインスタンス数に制限がある。

DedicatedHostとハードウェアインスタンス

インスタンスを占有する。
アプリライセンスでそうせざるを得ないような場合に使う。

”M”を基準に重視するリソースを選択する。

参加セッション５：Arcitecting for the Cloud 2019 ～クラウドにおけるアーキテクチャの設計原則～

このセッションの目的：考え方のきっかけ

AMI：Amazon Machine Image
バーチャルマシンのイメージから始まる。

EBS：Elastic Block Store
NWでアタッチされるストレージが使える。ほとんどの人がこれを使っている。

EBS Snapshot⇒別のAZへの移行ができる。

Shared VPC：VPC環境を複数アカウントで共有できる。

AZは本当に東京じゃないとだめなのか？を常に考えること。

障害を見越した設計

冗長化しましょう。
データをどのように持続させていくか。場合によっては、消えてもいいデータをクラウドに乗せるという考えもある。
複数データセンタを用いる＝複数AZを使いましょう。
AZを違うものにして、でも同じリージョンにする。ELB使うなどの工夫をする。

すべてのレイヤでの実装（セキュリティ）

できるところで徹底的にやりましょう。
出来てないところを認識しましょう。
使えるサービスは積極的に使いましょう。

自分に必要な権限だけを使いましょう。開発であっても。
定期的に監査しましょう。できるだけリアルタイムに。

ストレージ活用

S3, EBS　他にもあるある。
Amazon Elastic File Systemなんてものもある。

EC2を使うならEBSを使う。

保守性の実現

・Elasticにしましょう。伸縮自在。
・ブートストラッピング or Golden Image
Golden Imageの場合は伸縮できるように自分で作る必要がある。
・家畜として扱う。
入れ替えができるようにするという意味。ペットのように一つ一つに名前を付けて愛着を持つようなものではない。

並列で考える

とあるサービスの話。
EC2が1時間単位での課金だったころの話。1時間5分かかるような処理があった場合、2時間分の課金をする必要があった。
対策として、55分で必ずEC2を止めるというシステムがあった。しかし今は秒単位の課金になっている。55分で止めるという処理は今は無意味。

疎結合はあなたを楽にします

よいインタフェースを定義して疎結合にすると後々楽になる。SQSを使うだけで疎結合の実現はずいぶん楽になる。因みに、SQSはAWS最古のサービス。

実践（WEBアプリ編）

セキュリティは常に最優先
1. IAMユーザ／グループ
作ったIAMを複数人で共有するのはダメ。同じ権限が必要ならグループを作る。
2. Cloud Trail ～～
（スライドで紹介されているサービスは有償・無償のサービスが混じっているが）有償サービスでも安いので、使えるものは積極的に使うべき。
3. Enable and Disable region
自分の使うリージョンを認識して、使わないリージョンは使えないように設定する。

AWS上の基本的な構成

・静的情報：S3
・動的情報：・・・？メモできなかった。

セッション情報は外に出す

外に出すには、DynamoDBとかRedisとかを使う。
クライアントサイドで書き換えられても困らないものはCookieに書くのもあり。
EC2にはセッション情報を残さないこと！
SQSを使えるようにするだけで、圧倒的に楽になる。本当にデータの一貫性を保つ必要があるのか？を常に念頭に置いておくこと。

計算資源の使い捨て

本当にコンテナは必要か？
Golden Imageで実現できないか？
ブートストラップでは実現できないか？

Cloud Front

DDoSとか、脆弱性に対抗できる。1Tbpsを超えるような攻撃がAWSに来ているのが実情。
　⇒Cloud Frontを入れる。Cloud Frontさえ入れてしまえば、WAFを入れるのもわけない。
AWSにはシールドサービスがある。L4レベルの攻撃ならシールドサービスでOK（WAFでOKの聞き間違いかも）。
それ以上のものが必要ならシールドアドバンスを使う。シールドはデフォルトで使えるサービス。

AWS Well Architected Tool

発表者は「AWS Well Architected Tool」と「AWS TrustedAdvisor」をだいぶ押していた。

https://aws.amazon.com/jp/architecture/well-architected/
これを見ることを設計原則にする。困ったときはこれに照らし合わせて考えてみる。
以下のようなことが書かれている。
- MFAは有効にしているか
- DDoS対策はどうなっているか
- 3rdパーティは検討したか

AWS Trusted Advisor

発表者は「AWS Well Architected Tool」と「AWS TrustedAdvisor」をだいぶ押していた。

機械的にチェックしてくれる。経済的なところも見てくれる。
https://aws.amazon.com/jp/premiumsupport/trustedadvisor/

参考資料

ホワイトペーパー
Architecting for the Cloud：AWS Best Practice
AWS Well-Architected フレームワーク