aretan.jp

2015/08/04 Architecting on AWS

■クラウド移行に関する考慮事項
一度にすべてをクラウドに移行しないようにする
初期の移行対象は慎重に選択する
-> アーキテクチャ上の目的に応じて移行する
すべては移行しない
-> 廃止するアプリケーションがある場合、
-> 廃止するアプリケーションは移行せず、
-> クラウドで直接代替アプリケーションを設定する

■AWSシステム構築のベストプラクティス
故障に備えた設計で障害を回避
疎結合で柔軟に
伸縮自在性を実装
すべての層でセキュリティを構築
制約を恐れない
並列化を考慮
さまざまなストレージの選択肢を活用

■資格試験でよくでる
□ デプロイと管理
AWS CloudFormation
Amazon CloudWatch
AWS Elastic Beanstalk

□アプリケーションサービス
Amazon CloudSearch
Amazon SNS
Amazon SQS
Amazon SWF
Amazon SES

□コンピューティング
Amazon EC2

□ストレージ
Amazon S3
Amazon Glacier
Amazon EBS

□データベース
ElastiCache
DynamoDB
Amazon RDS
Redshift

□ネットワーキング
Amazon Route 53
Amazon VPC

■責任分担セキュリティモデル
AWSはクラウドのセキュリティ
お客はクラウド上のセキュリティ

■リージョンを決める方法
レイテンシー
費用
特徴
法令順守

■AZの中に入ってるやつ
EC2で動いてるやつ(サブネットで動くRDSとか)

■エッジロケーション
50以上のエッジロケーション
CloudFront、Route 53のみ実行される

■アカウントについて
マスターアカウント(契約者)
通常アカウント(アクセス権限が安全に制御される)
フェデレーションユーザー(既存の社内認証を使用してs3などのアクセス権を付与できる)
グループにポリシーを設定して、ユーザーを所属させる
マスターアカウントにはポリシーを設定できない

■ロールベースアクセス管理
論理的グループ化、職務的グループ化
権限の一括管理 (スケーラブル)
個人のチームが変わっても簡単に変更できる (ポータブル)

■IAMのベストプラクティス
多要素認証(MFA)を有効にする
マスターアカウントを構築や実運用に使用しない

■IAMロール
ポリシーはグループ、ユーザー、ロールに設定できる
「ロールはポリシーをまとめたもの」
EC2からS3を操作したいというような時によく使用される

■AWSの利用方法
AWSマネジメントコンソール
AWSコマンドラインインターフェイス
Software Development Kits
クエリAPI

■IAMによるセキュリティ強化
IAMを利用するとAWSサービスのアクセス権限を管理できる
一部のサービスはAmazon リソースネーム(ARN)を使用して制限できる

■IAMポリシー
JSON形式
ポリシーテンプレート
AWS Policy Generator
IAM Policy Simulator

☆STS Page50 自習

■VPCの保護
ルーティングルール
ネットワークACL -> 基本的なセキュリティポリシー、ステートレス
セキュリティグループ -> 完全な制御、ステートフル
で、すべてのレイヤにセキュリティを構築

■評価順序
インターネット
ルーティングテーブル
ネットワークACL
サブネット
セキュリティグループ
インスタンス

■VPCピア接続
同一リージョン内
2つのVPC間に1つのみ
IPアドレス空間の重複は不可
A-B-C の関係で直接ピア接続していないA-Cは接続不可

■VPCの考慮事項とベストプラクティス
CIDRブロックを慎重に選択
サブネットはシンプルにし、機能で分割
高可用性のためにVPC内にマルチAZを配備
セキュリティグループとNACLを使用
IAMユーザーとポリシーでアクセスを制御
インフラストラクチャの配備を自動化(CloudFormation)
Amazon CloudWatchを使用してVPCインスタンスとVPN接続の状態をモニタリング

■EC2のインスタンスタイプ
T2 汎用
M3
C3
R3
G2
I2
D2

■インスタンスストレージとEBSストレージの違い
インスタンスストレージ容量はインスタンスタイプによって違う
無料、非永続ストレージ、本来一時的なもの、停止終了で開放される
EBSは自由に大きさが変えれるスナップショットがとれる
停止終了でも影響しない、ネットワークを介す。

■起動の手順を自動化する方法
□内部から取れるインスタンスのメタデータ
http://169.254.169.254/latest/meta-data/
□ユーザーデータ
Cloud-Init、PowerShell

■Elastic IPとパブリック IP
インターネットにアクセスするにはEIPかパブリックIPが必要
EIPは一度取得すると開放するまで動的に変更できる(使って無い時に課金)
パブリックIPはインスタンスに付き再利用不可(無料)

■ENI
AZやVPCは越えれない、eth0はデタッチできない
管理用ネットワーク作成や、ライセンス認証のため、

■プレイスメントグループ
ノード同士でパフォーマンスを高める
10Gbpsネットワークで繋がる
同じAZ内なので可用性は高くない

■ハードウェア専有インスタンス
MSDNサブスクリプションのために利用される

■一般的データストレージの課題
拡張できない
需要を予測できない
費用がかかる
アーカイブ、バックアップ

■s3とebs
s3: 無限のキャパシティ、高い耐久性、バックアップ、オリジンサーバ
ebs: ハードドライブ、頻繁なデータ更新、自由にフォーマット

■ebs
EBSを別のAZに持って行きたい場合はスナップショットを取る
スナップショットは他リージョンにもコピーできる
継続してIOがある場合はProvisionedIOPSボリュームを使用
マグネティックはIOでも課金される
差分バックアップは内部的なシステム、1個目を削除しても問題無い
16TB以上使いたい場合はRAIDを使用
AES256で暗号化する機能がある

■ebsのベストプラクティス
早いEBSを使用するなら、より高いネットワークのあるインスタンスを使用
EBS最適化EC2インスタンスを使用する
EBSをストライピング(RAID0)を使用する

■s3
マルチパートアップロードAPIで5TBまでのファイルがアップ可能(通常5GB)
CAP定理：整合性△ 可用性○ 分断耐性○
書き込んだ後古いデータが返される事がある(結果整合性)
バケット名は世界で一つだけである必要がある

■s3のベストプラクティス
キーにはランダムハッシュプレフィックスを使用する(大量のデータの場合)
バックアップや一般的な格納のためにS3の高耐久性、高スループットのデザインを活用
高速な書き込みのために、並列スレッドやマルチパートアップロードを検討する
高速な読み取りのために、並列スレッドやレンジGETを検討する

■s3のセキュリティ
IAMポリシー、ACL (バケット、オブジェクトに設定)、バケットポリシー
SSLで暗号化されたエンドポイントからアップ&ダウンできる
s3のサーバー側暗号化(SSE)ができる
sdkでクライアント側のデータ暗号化で保護する

■Amazon Glacier
データのアーカイブに適したコールドストレージサービス
データの取得に数時間かかる事がある
デジタルメディアアーカイブ、財務記録、データベースの長期バックアップ
Storage Gatewayやs3からバックアップする
勝手にAWS256で暗号化される

2015/08/05 Architecting on AWS

■ELBによる疎結合
ウェブサーバーとアプリサーバーはELBで疎結合にしたほうがいい
ELBはレイヤ7はサポートしていない
クロスゾーン負荷分散：AZをまたいで負荷分散できる
プロキシープロトコル：IPアドレス等クライアント情報をヘッダーで渡す
スティッキーセッション：特定のインスタンスにバインドできる
コネクションドレイニング：セッションが終わってからバランサから外せる
ELBもIPを消費するのでELB用のサブネットを割く事がある

■複数リージョンのバランシング Route 53
加重ラウンドロビン：重みをつけてDNSラウンドロビンできる
DNSフェイルオーバー：バックアップサイトにフェイルオーバー
位置情報ルーティング：国によって異なるレコードを返す
レイテンシーベースルーティング：レイテンシが最小のエンドポイント
エイリアスレコード：IPの代りにCloudFront、ELB、S3などを指定できる
ZoneApex：example.comを登録できる

■NoSQLのユースケース
リーダーボードとスコア
クリックストリームまたはログデータ
一時データのニーズ(カートデータ)
ホットテーブル
メタデータまたはルックアップテーブル
セッションデータ

■DynamoDBのベストプラクティス
項目のサイズが大きくならないようにする
メタデータはDynamoDBに保存し大きいコンテンツはS3に保存する
時系列データを保存するために、テーブルを日、週、月ごとの単位で作成する
条件付き更新またはアプリケーション側でOCC更新を使用する
ホットキーおよびホットパーティション(データの偏り)を避ける

■RDSのユースケース
複雑なトランザクション
複雑なクエリ
ワークロードが単一ノードに収まる
高い耐久性

■RDSのベストプラクティス
DBインスタンスクラスを注意して選択
EBS最適化インスタンスを使用する
実稼働ワークロードにPIOPSを使用する
高可用性のためにマルチAZを使用する
リードレプリカを使用する
-> 読み取りのスケーリング
-> クロスリージョンレプリケーション

■CloudWatch
AWSリソースのメトリクス (CPU IO ネットワーク)
Billing
OS、アプリのログ
CloudTrailのログ

■CloudWatchはXenハイパーバイザー以上の中身は見れない
責任分担モデルの通りOSの中身までは見れない (メモリ プロセス)
CloudWatch APIでカスタムメトリクスに送る必要がある
カスタムメトリクスは課金やDIYが必要なのでよく監視ソフトが併用される

■CloudWatchアラーム
Amazon SNS
Auto Scaling ポリシー
Amazon EC2 アクション (再起動 停止)

2015/08/06 Architecting on AWS

■CloudFormation
JSONテンプレート -> AWS CloudFormation Engine -> スタック
JSONテキストエディター VisualOps CloudFormerなどを使用して作成
Resourcesに環境変数を入れてしまわないようにParametersで変数を作成
Regionの違いはMappingsを使用してパラメータを分ける (AMI IDなど)
Outputsでユーザーのために説明などの文字列を出力できる
開発環境はParametersで定義しConditionsで判定する
DependsOn属性で依存関係を表す事ができる (ゲートウェイ AutoScaling ELB EIPなど)
AWS::CloudFormation::WaitConditionでシグナルを待ち受けれる
OpsWorksでChef的な事ができる

■バッチ処理
SQS：コンポーネントの分離
SNS：通知の配信
SWF：タスクを整理
SES：大規模メール

■SQSユースケース
ワークキュー
オペレーションのバッファリングとバッチ化
リクエストのオフロード
ファンアウト
Auto Scaling

■Amazon SES 制限
サンドボックスはアドレス確認が必要
サンドボックス 200通/日 1通/秒
プロダクション 1000通/日 5通/秒

■GetSendStatistics API
配信の試行数
送信拒否されたメッセージ数
ハードバウンス数
苦情(受信拒否)数

■Amazon SESのベストプラクティス
受信者が希望するコンテンツを送信
メールを登録した人だけに送信
しばらくやり取りがなかった受信者は登録を解除
バウンスや苦情があったアドレスをリストから削除
Amazon SESコンソール、またはAmazon SES APIで送信アクティビティを監視

■Amazon CloudSearchのベストプラクティス
アップロードのためのバッチドキュメント
検索にはAmazon CloudSearchを使用し、ユーザ情報の完全記録には別のストアを使用する
よく検索対象になるデータをドキュメントに含める
ストップワードで一般用語を削除する
検索対象とするフィールドを絞って取得するデータ量を削減する

■スポットの使い方
オンデマンド料金の80%を越える価格で入札しない
10個以上のインスタンスを使わない
過去1時間の平均価格よりも10%高い価格で入札する