AWS Summit Tokyo 2019 day1 [AWSome Day at Tokyo Summit（半日）]

こちらは2019/6/13にQiita:Teamに投稿した記事をリライトしたものです。

# AWSome Day at Tokyo Summit（半日）

AWS Summitの1日目に参加して、
半日がかりのAWSome Day at Tokyo Summitというセッションを聞いてきました。
セッションメモなのでとりとめない感じになってます。

## AWS のグローバルインフラストラクチャとネットワークおよびコンピューティング

### VPC

特徴

- AWSクラウド内の仮装プライベートネットワーク

主な機能

- IPアドレスの指定範囲
- ルートテーブルによるルーティング設定
- ネットワークゲートウェイ


コンピューティングサービス

- EC2
- Lambda
- Lightsalil
- ECS
- EKS
- Fargate

### EC2

特徴

- キャパシティーを拡大/縮小可能
- 支払いは実際に使用したキャパシティー分のみ
- 複数のリージョンおよびAZにまたがったデプロイで信頼性を向上

インスタンス起動の流れ

- リージョンの選択
- AMIの選択
- インスタンスタイプの選択
- 配置先・VPC・サブネットの選択
    - 「高度な詳細」にてシェルスクリプトの設定が可能
- ストレージの選択
- タグの設定・追加
- セキュリティグループの設定
- キーペアの選択・作成

### CloudWatch

- AWSクラウドリソースをモニタリングするサービス
    - アラーム機能、通知
        - アラームからLambdaをキックして負荷を下げるような処理を行うということもできる
- 全体的なリソース消費パターンを可視化
- ユーザー独自のメトリクスを定義可能

### ELB

特徴

- 複数のインスタンスにトラフィックを分散
- 正常に動作していないEC2インスタンスを検出して除去するためのヘルスチェックをサポート

種類

- ALB
    - リクエストレベルで動作する（レイヤー7）
    - HTTPとHTTPSトラフィックのロードバランシング
- NLB
    - 接続レベルで動作する（レイヤー4）
    - TCPトラフィックのロードバランシング

### EC2 Auto Scaling

特徴

- EC2のキャパシティーを自動的にスケーリング
- 追加料金不要
- Auto Scalingグループ
    - Auto Scalingグループ内のインスタンスは、インスタンスのスケーリングと管理のための論理グループとして扱われる
    - 最小サイズと最大サイズを設定
        - 最小サイズ以下になると自動的に最小サイズまで復元する
            - 何らかの問題が発生してインスタンスがダウンしても自動で復活してくれる
動的スケーリングの種類
- CloudWatchアラームを使用したスケーリングポリシー
- 維持したいメトリクス地を指定するターゲット追跡スケーリングポリシー
- 予測スケーリングポリシー

## ストレージとデータベース

### EBS（サーバー自身からしかアクセスできない）

特徴

- 一貫性のある低レイテンシーのパフォーマンスを提供する永続的なブロックレベルのストレージボリューム
- AZ内で自動的にレプリケート
- S3にスナップショットを安全に保存
- EC2のボリュームとして割り当てられる


ユースケース

- OS - ブート/ルートボリューム
- データベース - パフォーマンスのニーズに合わせてスケール可能
- エンタープライズアプリケーション
- アプリケーション

ボリュームタイプ

- コールドHDD sc1
- スループット最適化HHD st1
- 汎用SSD gp2
- プロビジョンド  IOPS SSD io1

ライフサイクル

- CreateVolumeの呼び出し
    - 1GB~16TB
- AttachVolumeを呼び出して1つのEC2と関連づける
- EC2インスタンスOSからのフォーマット
- スナップショットをS3に保存
- DetachVolumeの呼び出し

### S3

特徴

- インターネット対応のストレージ
- 常にオンラインでhttpでアクセス可能
- どのような量でもデータの保存、取り出しをいつでも、ウェブ上のどこからでも実行可能
- スケーラビリティ、信頼性、耐久性に優れ、かつ高速

概念

- データがオブジェクトとしてバケットに保存される
- オブジェクトとはファイルとそのファイルを説明する任意のメタデータで構成される
- アカウントあたり最大100バケット
- バケットとそのオブジェクトのアクセスログを制御できる

バケット

- S3を利用する際のトップレベルのネームスペース
- ストレージとデータ転送料金が発生したアカウントを特定する
- アクセスコントーロールにおける役割を果たす
- 使用状況レポートの集計の単位として機能する
- 作成されたAWSリージョンに限らず、世界的に一のバケット名をつける必要がある

ユースケース

- アプリケーションアセットの保存
- 静的ウェブホスティング
- バックアップと災害対策
- ビッグデータ用おステージング領域
- その他

### RDS

特徴

- コスト効率にすぐれ、　サイズ変更が可能なキャパシティー
- 時間のかかるデータベース管理タスクが不要になる
- Aurora, MySQL, MariaDB, Microsoft SQL Server, OracleおよびPostgreSQL

DBインスタンス

- DBインスタンスはRDSの基本構成要素である
- DBインスタンスはクラウド内の独立したデータベース環境である
- DBインスタンスには複数のユーザーが作成したデータベースを含めることができる

バックアップ

- 自動バックアップ
    - データベースを特定時点まで復元する
    - デフォルトで有効
    - 最大35日間までの保持期間を選択できる
- 手動スナップショット
    - スナップショットから新しいDBインスタンスを作成できる
    - ユーザーによって開始される
    - ユーザーによって削除されるまで持続される
    - S3に保存される

セキュリティ

- IAMポリシーを利用してリソースへのアクセスを許可する
- セキュリティグループを使用する
- DBインスタンスにはSSL接続を利用する

リードレプリカ

- Read Only
- 非同期レプリケーション
- 必要な時にマスターに昇格

### Aurora

特徴

- MySQL5.6/5.7とPostgreSQL9.6に互換性あり
- 自動的にスケーリングを行う（最大64TB）
- 標準で効果要請を実現

### DynamoDB

特徴

- 保存できるデータ量に制限はなし
- SSDを使用してハイパフォーマンスを実現
- 各テーブルに必要なリクエストキャパシティーを容易にプロビジョニング

## AWS のセキュリティの基本

### VPCのネットワーク制御機能
- ファイアウォール
    - セキュリティグループ
        - for インスタンス
    - ネットワークACL
        - for サブネット
- ネットワークの経路制御
    - VPC内もしくはVPC内外の通信経路を設定する
    - ルートテーブル
- インターネットとの通信
    - インターネットゲートウェイ
- オンプレミス環境との接続
    - Direct Connect/VPN

### AWSの認証とアクセス管理

IAM

- ユーザとグループの作成
- 権限とロールの付与
- 認証
    - AWSマネジメントコンソール
        - ユーザー名とパスワード
    - AWS CLIまたはAWS API
        - アクセスキーIDとシークレットキー
- 認可
    - ポリシーの割り当て
        - ユーザー
        - グループ
        - ロール
            - EC2からS3などAWSサービス間のアクセスの際はアクセスキーID&シークレットキーよりもロールで権限付与をする方が安全
            - Systems Manager -> セッションマネージャー から各サーバーのコンソールを起動できる

## Well-Architected Framework と料金の話

### Well-Architected Framework
- ベストプラクティスかどうかを問いかける質問集
- AWSエキスパートが作成した一連の質問を利用してアーキテクチャを慎重に検討できるようサポート
一般的な設計原則
- 必要キャパシティの推測をやめる
- 本稼働スケールでシステムをテストする
- アーキテクチャの実験を容易にするために自動化を取り入れる
- 革新的なアーキテクチャを許容する
- データ・ドリブンでのアーキテクチャ変更
- Game day: 本番で想定される事態をあらかじめテストする
フレームワークの5つの柱
- 運用上の優秀性
    - システムを実行およびモニタリングしてビジネスの価値を生み出し、サポートのプロセスと手順を継続的に向上する能力
        - 準備
            - 運用上の優秀性を実現するには、効率的な準備が必要
        - 運用
            - 運用上のイベントに対応するための手順の作成と使用の有効性の検証
        - 進化
            - 変化に対応して進化を支援できる運用設計と、運用から学んだことの取り組み
- セキュリティ
    - リスクの評価と軽減戦略によって、ビジネスの価値をうみだしながら、システム、アセット、情報を保護する能力
        - アイデンティティとアクセスの管理（IAM）
        - 検出制御
        - インフラストラクチャの保護
        - データ保護
        - インシデントへの対応
- 信頼性
    - インフラまたはサービスの障害からの復旧、必要に応じた動的なコンピューティングリソースの確保、設定ミスや一時的なネットワークの問題などによる中断を軽減するシステムの能力
        - 基盤
        - 変更管理
        - 障害管理
- パフォーマンス効率
    - リソース使用量の削減
- コスト最適化
    - 不必要なコストの排除
料金の基礎
AWSの料金モデル
- 従量課金制
- 予約による値引き
    - リザーブドインスタンスの購入
    - 最大75%節約
    - オプション
        - 全額前払い（AURI）
        - 一部前払い（PURI）
        - 前払いなし（NURI）
- 使うほど単位あたりの支払いをさらに値引き
    - ボリュームディスカウントを実現
    - 使用量が増えるほど節約
    - 階層化されたサービス料金
    - 受信データ転送は無料
    - ストレージサービスのオプション
- AWSの拡大に合わせて支払いをさらに値引き
    - AWSは数十回の値下げを行っている
    - AWSの拡大に合わせて事業運営にかかるコストの抑制に注力
    - スケールメリットがもたらすコスト削減はお客様に還元
- 無料利用枠
- 追加料金なしのAWSサービス
    - VPC
    - Elastic BeanStalk
    - CloudFormation
    - IAM
    - Scaling

### 料金に関する詳細情報

EC2

- 秒（Amazon LinuxとUbuntu）/時間（その他）単位による請求
- リソースの料金は実行中にのみ発生
- インスタンスの設定
- 購入オプション
    - オンデマンドインスタンス
        - t2.micro 11,13USD/month
    - リザーブドインスタンス
        - t2.micro 4.78USD/month
    - スポットインスタンス
        - t2.micro 3.6USD/month ~
- インスタンス数
    - 複数インスタンスをプロビジョニングしてピーク時の負荷を処理
- 負荷分散
    - ELBを使用してトラフィックを分散
    - 以下に基づき月額料金を計算
        - ロードバランサーの実行時間数
            - 0.0243USD/hour（17.79USD/month）
        - ロードバランサーが処理するデータ数
- CloudWatchを使用してインスタンスをモニタリング
    - 基本モニタリング（デフォルト）
        - 無料、5分単位
    - 詳細モニタリング
        - 有料、1分単位
- Auto Scaling
    - インスタンスの数を自動的に調節
    - 追加料金の発生なし
- Elastic IPアドレス
    - 実行中のインスタンスに関連づけられた一つのElastic IPアドレスを無料で利用
   
S3

- ストレージの種類
- リクエスト
    - リクエストの数
    - リクエストのタイプ
        - 1000リクエストあたり PUT:0.0047USD, GET:0.00037USD
- データ転送量
    - 0.114USD/GB

## クラウド時代の学習スタイル。 エンジニア主体のビジネス価値創出をめざして

### AWSはメカニズムを大事にしている

人間が都度作業をすることによってミスが発生する
→それを防ぐために自動化できるものは自動化する
→これをメカニズムと呼んでいる

### Infrastructure as Code

- リソースはAPI経由でプロビジョニング
- 定義ファイルによる、効率化と自動化
- エラーやセキュリティ違反の除去

### 2つのクラウドジャーニー

- サービス系システム
    - 顧客体験の強化
    - UIの連続的改善
- 基幹系システム
    - システムの安定化
    - データの完全性

### モダンアーキテクチャ
- マイクロサービスアーキテクチャ、サーバーレス、コンテナ
    - 開発速度の向上
- データレイク
    - 機械学習やIotをより効率的に

### マイクロサービスアーキテクチャ

- モノリシックアーキテクチャ
    - 密結合
    - メンテナンスと維持が難しい
    - ビルド・テストに時間がかかる
    - デプロイがボトルネック
    - スケールが難しい
- Service-Oriented Architecture(SOA)
    - HTTPSのAPIのみで連携
        - 単一の目的
        - お互いはブラックボックス

### サーバーレス
マネージドサービスとサーバーレスコンピューティング

- サーバー管理は不要
- 利用状況に応じて自動で拡張
- 利用していないリソースは支払い不要
- 可溶性や耐障害性は実装済
 Lambdaによる言語の使い分け
- アクセスがまばら
    - Python, Node,js（書道が早い）
- 常時アクセス、ないしは大量のCPU
    - Java, Go（初回実行コストが重たいが動作は高速）

### コンテナ

- オーケストレーションサービス
- AWSのコンテナ関連サービス
    - ECS
    - EKS
    - Fargete for ECS
    - Fargete for EKS（サービス開発中）

### データレイク
- S3
- Athena
    - SQLクエリ実行
        - 必要データの取り出し
- AWS Glue
    - データのETL作業
        - 整形、構造化

## 感想
- 幕張メッセということもありフェス感がすごい
- 12:00から40分×6コマぶっ通しで見ましたが、結構疲れました...
    - AWSの基本的な内容についてのセッションで、だいたい知っているからこそ知識の整理という意味ではよかったです
- いろんな会社がブース出展してましたが、クラウド運用とか監視とかそっち系が多くてアプリケーションエンジニアにとってはあんまりかも