AWS Night School

Twitterのハッシュタグは #jawsug_bgnr

AWS Night school 第1回（AWSJ 亀田さん）

ビルディングブロック

ブロックを組み合わせるようにサービスを組み合わせて利用するという思想

AWS利用料の一般的な内訳

EC2・RDSが利用料金の9割
→EC2・RDSから学習すると良い

AWSの利用額が怖い

Billing Alertを活用しよう
一定金額を超えたらアラート（メール）を飛ばす

AWSのグローバルインフラストラクチャ

大阪リージョンは単独で利用できないので、東京リージョンとセットで利用する
※リージョン＝国・地域

東京は4つのアベイラビリティゾーンで構成されている
※アベイラビリティゾーン＝データセンター

リージョンとアベイラビリティゾーン

アベイラビリティゾーンをまたがないとSLA適用外
1台構成は要件を満たしているか要確認

アベイラビリティゾーンを跨ぐ場合、1ms程度の時間が掛かる

マルチアベイラビリティゾーンでデータセンターレベルで単一障害点を失くす

EC2・EBS

コンピューティング処理能力を変更可能
Linuxの場合、1分単位で課金

インスタンスのCPU・メモリを変更する場合、再起動が必要

前払い機能で割引あり（リザーブドインスタンス）

東京リージョンは高い（アメリカより）
データ分析など、データの転送速度よりCPUが必要な場合はアメリカのリージョンを使うと良い

インスタンスタイプとは？

C3.8xlarge のように表記する

C：インスタンスファミリー
3：世代数（より大きいものが良い）
8xlarge：スペック（より大きいほうが性能が良く料金が高い）

初めて触る場合、M5がオススメ

インスタンスのユーザーデータ

インスタンス起動後にスクリプトを実行することができる

ストレージ

EBS 永続的に保存できる
インスタンスストアシャットダウンするとデータが消える

AWSは障害が起きない×
障害は発生しているが即時に別ハードウェアで起動するなどして瞬断で復旧している○

EC2が不安定なときは停止・起動で安定する場合あり
何故か？可能な限り別ハードウェアで起動するため、不安定なハードウェアから脱出できる

EC2とストレージはネットワークで繋がっているため、ここがボトルネックになるケースがある
「EC2最適化」でEC2を起動すると良い（ネットワークとストレージ用ネットワークが別で提供される）

10万IPOSを超えるようなアクセスの場合、EC2に直付けのインスタンスストアを使用すると良い
シャットダウンでデータが消えるため定期的にEBSやS3に退避すること

EBS

アベイラビリティゾーン内で自動的にレプリケートしている

1GiB〜1TiBのEBSマグネティックボリューム
最大16TiBのSSDボリュームを提供
基本的にSSDを利用すると良い

複数のEC2から一つのEBSへのアクセスはできない
NASのように利用する場合はEFSを利用すると良い

ストレージパフォーマンスが必要ならプロビジョンドIOPSを利用すること

EBSスナップショットは差分バックアップで取得される
取得したバックアップは自動的に圧縮される
そのため、見積もりがしにくい点に注意

インスタンスメタデータ

169.254.169.254にアクセスすることで取得可能

GitHubにAWSのシークレットキーをアップロードしないこと

クロールしているユーザーがいて、仮想通貨のマイニングに使用される

AWSでもGitHubにシークレットキーがアップロードされていないかクロールしているが、
AWSではお客様のアカウントを操作しないというポリシーになっているため連絡のみ
基本的には自己防衛

第2回ではS3・RDSを予定

Auroraの凄さを振り返る（クラスメソッド株式会社大栗宗さん）

Auroraの凄さを振り返る
https://speakerdeck.com/maroon1st/aurorafalseqi-sawozhen-rifan-ru

JAWS-UG 初心者支部#12 AWS Night schoolでAuroraの凄さを話してきた #jawsug #jawsug_bgnr
https://dev.classmethod.jp/cloud/aws/jaws-ug-bgnr-13-aurora-session/

Auroraの特徴

クラウド自体にAmazonが再設計したRDBMS
MySQLとPostgreSQL互換

MySQLの最大5倍
99.999999999%の堅牢性（S3と同じ）

移行サポートが豊富
低コスト（実際に利用した分だけ料金が発生）
→将来のデータサイズを見越した設計をしなくて良い

AZを跨いだ統一的なストレージボリュームがある

既存のAWSサービスを組み合わせてAuroraが実現されている
ユーザーからは隠蔽されており、ユーザーは意識せずに利用できる

Well-Architected Framework

信頼性の柱

6重化された分散ストレージ
1つのAZに2個、3AZでデータを保存

１つぐらいデータセンターがなくなっても運用可能

なぜ6重化？
クォーラムモデルによる多数決のため
本来なら3重化でも良いが、AZ停止のような大規模障害にも耐えるため6重化

ストレージが独立している
フェイルオーバーが速い（データリカバリが殆ど無い）

パフォーマンス効率の柱

レプリケーションによるスレーブへの書き込み負荷がない
スレーブにはログの位置情報のみを伝える（ストレージが共用なので可能）
（通常のRDSはスレーブにもマスターと同じ書き込みを行っているため負荷がある）

レスポンスタイムが安定している

MySQL限定だが、特定のJoinが高速化されている
Joinの種類やスキャン方法を追加している

MySQLが苦手なフルスキャンが高速化されている

コスト最適化の柱

Multi-AZの予備機をリードレプリカとして利用できる
（予備機も含めてすべて利用可能）

負荷に合わせてリードレプリカをオートスケーリングできる

Aurora Serverlessで待機コストを極小化
停止後の起動に25秒ほどかかることに注意

運用上の優秀性

コネクションを切断せずにパッチ適用可能（例外あり）

高速フェイルオーバー（数秒）
通常はDNSで切り替えるが、
マスターフラグ・スレーブフラグがあり、そこをクライアントで判定して切り替えることで高速化可能

backtrack：DBデータを任意の時点に戻すことができる
drop tableのオペミスにも活用できる

Database clone：即座にDBデータを複製

Performance insights搭載：パフォーマンス分析・トラブルシューティングが可能
DBの待ち時間の可視化
クエリ単位でも状況確認可能

IAM認証でログインできる

カラム追加も高速

AuroraからLambdaを実行可能