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を実行可能