AWS

AWS ソリューションアーキテクト アソシエイトのお勉強

 

AWS  Well-Architected フレームワーク

AWS Well-ArchitectedとはAWSでインフラ構築を行う設計原則

  1. 安全かつ高パフォーマンス
  2. 障害耐性
  3. 効率的なインフラ構築

AWS Well-Architectedで構成されているかレビューするツール「AWS Well-Architected Tool」がある。

 

フレームワークの構成要素

  • 一般的な設計原則
  • 5つの柱(セキュリティ、信頼性、パフォーマンス効率、コスト最適化、運用性)
  • 確認事項

 

一般的な設計原則

  • 容量の判断を勘に頼らない
    ある程度のスペックで初めて本番運用で見直す。稼働初めは大きめのインスタンスで、適切なインスタンスサイズに最適化させる。
  • 本番のスケールでテストする
    テスト時に本番相当の環境でテストを行い、テスト後は破棄する。
  • 実験を容易にする為のインフラ構成の自動化
    自動化しておけば、安心してデプロイできるので顧客への価値提供頻度をあげることが出来る
  • 革新的なアーキテクチャの取り入れ
    サービスリリース時から時が過ぎれば、ビジネス環境はどんどん変化していく。クラウド上での自動化とテストを行えるようにしておくことで、革新的なサービスを取り入れ、コスト削減や運用負荷削減といったことが容易になる。
  • データドリブンでのアーキテクチャの変更
    クラウドでは各メトリクスを自動取得してくれる、メトリクスのデータを利用した意思決定を行うことが出来る
  • ゲームデー
    本番環境で想定される事態をあらかじめテストすること。イベントを再現することで、改善可能な箇所を把握し、組織的にイベントに対してどう対応するかといった計画と改善を行える。

 

5つの柱

1. セキュリティ

すべてのレイヤーでのセキュリティを適用、多段でのセキュリティを実装しよう。セキュリティは鎖のようなもので1つが脆弱だとすべてを台無しにする。

  • トレーサビリティ
    すべての操作を追跡可能にしておく
    誰が、いつ、何をしたか。
    IAMやCloud Trailといったもので実装出来る。
  • 最小権限の原則
    AWSリソースの操作では利用するAPIと対象のAWSリソースを特定し、必要最低限の権限のみを与える。認証情報が漏れた時に被害を最小化出来る
  • システムの保護にフォーカス
    AWSは世界でもっとも堅牢なセキュリティを持つサービスの1つであるが、サービスとして責任共有モデルであり、利用する場合はどこまでがAWSが責任を持ち、どこからが利用者が責任を持つのかといった責任範囲を適切に理解し、自環境のアプリケーション、データ保護に対して責任を持って保護する必要がある。
  • セキュリティのベストプラクティス
    セキュリティパッチといった適用を少しのプログラムを書くことで自動化を実装できる。CloudTrailや他セキュリティサービスを利用して自動化を行おう。

 

2. 信頼性

インフラサービスの障害を復旧したり、自動的にコンピューティングリソースを獲得したり、設定ミスや一時的なネットワーク障害を軽減する為のシステムの能力

 

  • 復旧手順のテスト
    復旧手順は実際の環境でテストすること。「フェイルオーバを切り替えた時に想定した通りに上手く切り替わらなかった」ということがないようにする。実際にリカバリ出来るかをテストしておくこと
  • 障害からの自動復旧のテスト
    パフォーマンスをモニタリングしておき、閾値を超えた時にトリガーで自動で処理でイベント処理が行われるようにしておくこと。こうすることで自動的に障害を検知し、追跡し、障害の回避または復旧プロセスを自動化できる。人の手や監視を介さないことで復旧が自動化できる。
  • 水平方向にスケールして集約システム能力を強化
    1つの大きなシステムにするのではなく、複数の小さなシステムに置き換え、1つの障害がシステム全体に及ぼす影響を軽減化し、局所化する。サーバ台数を並べることで、負荷分散をしながら耐障害性を高めることが出来る。
    実装として、
    ・水平方向のスケールアウト、
    ・アプリケーションのマイクロサービス化
  • キャパシティ推測を不要に
    ・障害の原因の多くの一つがリソース不足。容量だったり、処理能力だったり。
    ・AWSでは需要に応じてリソースを追加したり、スケールを行う仕組みがあるので積極的に活用を行う。
  • 自動化における変更管理
    ・インフラ変更の自動化を行うこと、自動化した変更内容もしっかり管理する。
    ・いつ、誰が、何をどのように変更したのか?

 

3. パフォーマンス効率

システムの要求に合わせてコンピューティングリソースを効率的に使用し、需要の変化、技術の進歩に合わせて効率を維持する能力

  • 先進技術の一般化
    NoSQL, メディア配信、機械学習など新技術の管理をクラウドベンダーにおくことで、実装の難しかった技術が簡単に利用できるようになる。
    管理する人的リソースも削減が出来る
  • グローバル化に即時対応
    リージョン毎にシステムを配置できるから、世界中に顧客に地理的に近い場所にシステムを配置できる。低レイテンシーで顧客体験を向上させよう。
  • サーバレスアーキテクチャ
    プログラムコードのみでサーバを意識することなく、需要に応じてスケールしてくれる
  • 実験頻度の増加
    異なるサイズのインスタンス、ストレージ、設定を使用し比較検討できる。その時に従量課金だから、さまざまな環境で実験が可能
  • 適合したテクノロジーアプローチ
    最適なテクノロジーでアプローチすること。

 

4. コスト最適化

不要なコストや最適でないリソースを回避、削除すること。

  • 消費モデルの採用
    利用した分だけコストを支払うようにしよう。
    開発環境やテスト環境はだいたい一日8時間しか利用してないことがほとんど。利用していない時間は停止するなどしてコストを削減できる。
  • 大幅なスケールメリット
    数十万単位でユーザがいるから規模の経済が働いていて、ユーザはとても安くクラウドを利用できます。
  • データセンターへの運用投資が不要
    データセンターの業務はクラウドが行うので、自社の顧客やビジネスに集中することが出来る
  • 投資分析と要因把握
    クラウドを利用するとシステム使用料とコストを正確に特定できる。
    個々の組織のビジネスオーナーに帰属させることが出来る。
    →投資対効果(ROI)測定を助け、リソースの最適化、コスト削減につなげることが出来る。
  • マネージドサービスによる所有コストを減らす
    データベースの保守管理やサーバ管理といった複雑な運用負荷を削減する
5. 運用性

サポートプロセスと手順の継続的な向上を実現するためのシステムを実行、モニタリングする能力

変更管理、継続的な運用プロセス、手順の改善、通常時・障害時の運用業務のトピック

 

  • コードによるオペレーションの実行
    何度も実行するプロセスがある場合は自動化すること、コード化を行い、構成管理や変更管理を行うこと
  • オペレーションプロセスをビジネス目標に合わせる
    不要なメトリクスは取得しない。
    必要のないグラフは取らない、不要な情報は対応する時に邪魔になる。
  • 定期的に小規模に、増分変更を行う
    変更を局所的に小規模に行うと、
    ・変更箇所が小さく痛みも少ない。
    ・局所化するのでロールバックも容易になる
  • 予期しないイベントの応答テストをしよう
    予期しない運用イベントに対する対応手順をテスト化し理解する。
    ゲームデーを設定して、実際に障害やイベントを発生させて問題なく対応できるように備える
  • イベントや障害から学ぶ
    障害は記録し、後で改善できるようにレビューを行おう。
    定期的なプロセス改善が高い運用性に繋がる。
  • オペレーション手順を最新に保つ
    プロセスと手順は常に最新に保っていなければいけない。
    文書化も大事だが、手順や構成をコード化し自動化を行おう
    AWSは進化する、その進化に合わせた構成管理や変更管理を最新に保つ必要がある。

 

 

Design for Failure(故障の為の設計)

  • 一部のインスタンスが故障しても動き続けられるようにする
  • どんなに堅牢にしても絶対に止まらないシステムはない、止まっても良いようにする
    具体的には、
    動的な機能が停止した時やサーバエラー500系が発生した時に、
    静的ページに表示を切り替えるなどとする。
    そうすることでユーザに機能は提供できないが、サービスが動いているように見せる。不安感を抱かせない。

実装として、

AWS Route53のDNSフェイルオーバ機能などがある。

AWS Route53のDNSフェイルオーバ

死活監視を行い、死活先の応答がなくなった時に、スタンバイしているサーバにDNSを切り替える。

 

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

 

リージョン

  • 地理的に離れた領域
  • 北米ではオレゴン、バージニア北部など細かくわかれている

基本的に東京リージョンにシステムを建てる

 

アベイラビリティゾーン

Desing for Failureを実現するのに必要。アベイラビリティゾーンは1つ以上の独立したデータセンタで構成されます。

  • ネットワークや電源、空調などすべてのものはダウンするという設計思想、それを実現する為にデータセンター単位でも冗長化を行う必要がある。
  • AWSでは1つのアベイラビリティゾーンに1つのインスタンス、複数のアベイラビリティゾーンにインスタンスを配置することで、耐障害性を飛躍的に高めることが出来る。

 

グローバルサービス

一部サービスではリージョンに依存しないマネージドサービスがある。

  • Route53
  • CloudFront
  • WAF

など。リージョンに依存しないのですべてのリージョンで利用が出来る!

 

エッジロケーション

  • CloudFrontのコンテンツやRoute53のDNSサービスを提供するためのデータセンタ
  • ユーザは地理的に近いエッジロケーションからコンテンツを配布され利用出来るので低レイテンシーなサービスを実現出来る

 

 

セキュリティ

 

責任共有モデル

AWSとユーザでどちらが一方ではなく、両者で利用形態に応じて責任を分担するPaaSである。

 

AWSの責任

すべてのサービスを実行するインフラストラクチャにセキュリティ保護を実施している。

  • 物理的なセキュリティ
  • 物理ホスト上のハイパーバイザのセキュリティパッチ適用
  • データセンターへの入室管理
  • サーバへの物理レベルでのアクセス制御

ユーザの責任

仮想ネットワーク、データ暗号化、FWの設定、OSの内部、AWSの各種設定について管理と運用を行う責任を負う

  • OS、ミドルウェアのセキュリティパッチ適用
  • アプリケーションのセキュリティパッチ適用
  • アプリケーションレベルのアクセス制御
  • サーバへのネットワークレベルでのアクセス制御

 

セキュリティ強化ツール
  • Cloud Trail
    AWS操作履歴の記録
  • セキュリティグループ
    ファイアウォール
  • WAF
    WEBアプリケーション防御
  • KMS
    データ暗号化の鍵管理

 

 

AWSの権限管理

ルートアカウントの取り扱い

通常時のルートアカウントの利用は推奨されない

  1. 初回作成後にIAMユーザを作成する
  2. 通常時はIAMユーザを利用し、ルートアカウントを利用しない
  3. 使わなくなったルートアカウントは多要素認証(MFA)を有効にしてロックをかける
  4. ルートアカウントでしか利用できない申請のみ、MFAを利用してログインを行い利用する

 

IAM Identity and Access Management アイアム

認証とアクセス管理をセキュアに扱うことができる。

  • IAMユーザ
    個人またはサービス毎に発行する。
    Cloud Trailなどのサービスでは、IAMユーザ毎に操作履歴を残すので、ユーザ毎にいつ誰がどのような操作をしたのか特定する為に、ユーザ毎に発行することが推奨される
  • IAMグループ
    IAMグループ毎にIAMポリシーを付与でき、役割や組織毎に権限管理をグループ化して設定が出来る
  • IAMポリシー
    アクセスレベルの許可や不許可をIAMユーザ、グループに適用する為のポリシー。サービスやAPI毎に細かくポリシーが存在する。

IAMの管理手順

  1. IAMグループを作成する
  2. IAMユーザを作成してグループに参加させる
  3. IAMポリシーを作成し、操作可能なAWSリソースを設定
  4. IAMポリシーをIAMグループに割り当てる

 

アクセスキー、シークレットキー

  • CLIやSDKでの利用で利用する。
  • IAMユーザでアクセスキーとシークレットキーを発行する。

 

IAMポリシーの利用の注意点

  • 各最小限のポリシーをアタッチすること
  • 定期的なキーのローテーションを行う
  • プログラム内にハードコードせず、IAMロールを利用する

特にEC2を利用する際は、IAMロールを活用し絶対にEC2内にアクセスキーやシークレットキーといった情報をハードコードしないこと。

 

クロスアカウントアクセス

AWSアカウントAからAWSアカウントBのAWSリソースを扱う時に利用する機能。

 

AWS SDKでプログラムからAPIを利用する

AWS SDKを利用する場合にアクセスキーとシークレットキーが必要

 

MFA(多要素認証)

物理デバイスや仮想デバイスを用いた多要素認証が可能、コンソールログインへのセキュリティが高まる。

 

ID Federation / SAML(Security Assertion Markup Language)

  • ID Federationは企業で導入されている認証の仕組みとAWS認証を紐づける。
  • SAMLやFacebookなどのウェブID、Active Directory, LDAPなどのユーザ管理とも連携が可能。
  • ADやLDAPのユーザにS3のアクセス権限を紐づけることもできる。

 

最小限の原則

最小限の原則の適用例

  • 請求情報管理者(経理)
    →請求情報のみにアクセス許可を行う
  • 参照のみの管理部長
    →ReadOnlyアクセス権限のみ付与
  • レポートをS3にアップロードするユーザ
    →特定のS3バケットの書き込み権限を付与
  • EC2に複数用途のアプリケーション
    →複数の権限を1つのIAMロールにつけることは推奨されない
    役割が2つなら、
    2つのIAMロール、2つのEC2を作成してIAMロールをアタッチする

 

 

AWSのセキュリティ管理

 

CloudTrail(監査ログ)

AWSアカウントのガバナンス、コンプライアンス、運用とリスク監査などを支援するサービス。外部監査を進める上で必須の機能

  • いつ、だれが、何を行ったかを記録する
    実現する為に、IAMユーザはユーザ毎に適切に発行を行うこと
    1つのアカウントを共用で使い回すことは推奨されない
  • CloudTrailはデフォルトでON
    全リージョンでデフォルトで有効になっている
  • 長期ログの保存先にS3
    一工夫
    ・取得元のアカウントからは書き込みのみで読み込みはさせない
    ・S3のバージョニング機能を有効にする
    アカウントがハックされて不正ログに上書きされても、過去の情報が記憶されるようにしておくことでよりセキュアな管理を実現出来る。

 

AWSのサポート

  • AWSでの本番運用ではビジネス以上のサポート
  • 大規模システムではエンタープライズを契約することが推奨される。

 

 

 

ネットワーキング、コンテンツ配信

 

仮想ネットワーク

従来のデータセンター構築の流れ

  1. データセンターとの契約
  2. ラックの調達
  3. 電源の用意
  4. ネットワーク機器の設計、選定、導入、設定
  5. ネットワーク冗長化
  6. メンテナンス、障害対応

AWSではこれらが抽象化して意識せずにアカウント開設後に即時利用になる。

 

VPC(Virtual Private Cloud)

  • AWS上にプライベートネットワークを作成する機能
  • インターネットと直接接続出来ない社内ネットワークとのVPN接続、専用線接続(AWS Direct Connect)が利用可能になっている

 

VPCの作成
  • VPCに対してIPv4アドレスの範囲をCIDRブロック形式で指定する必要がある。
  • また後からアドレスレンジを拡張できる
サブネット
  • サブネットはVPCをさらに分割したもの、VLAN
  • サブネットはアベイラビリティゾーンを跨げない。
    アベイラビリティゾーン毎にサブネットを作成する

 

VPC作成の注意点
  • ネットワークアドレスを重複させないように設計する。
    VPC同士で接続することを考えて、後でVPC同士でアドレスが重複しないようにCIDR設計をする
  • 最低/28から使用する
  • 各サブネットでは、CIDRブロックの最初の4つのIPアドレスが予約されている!

 

10.0.0.0/24のサブネットのIPv4の予約例

  • 10.0.0.0 ネットワークアドレス
  • 10.0.0.1 VPCルータ
  • 10.0.0.2 DNSサーバ
  • 10.0.0.3 将来の為にAWS側が予約
  • 10.0.0.255 ブロードキャストアドレス

/28の場合は、11個のアドレスしか利用できないので注意が必要

 

プレフィックス長 AWSサブネットで利用可能IPアドレス
/28 11
/27 27
/26 59
/25 123
/24 251

4つのIPアドレスを引き算する

 

ELB, ALN, NLBロードバランサのサブネットはIPレンジに余裕を持たせる
  • IPアドレスが確保できないとスケール出来ない

 

ルートテーブル

サブネットとVPC内での通信を関連付け、宛先をみてどこへ通信するのを定義する(ルーティング)。LinuxやWindowsにおけるrouteと同様。

オフィスへの通信はDirect Connectへ通信させる、未定義の通信はすべてインターネットに流すなどと定義するといったことが可能になる

ルートテーブルの例

  • 0.0.0.0./0 -> IGW

 

パブリックサブネット

VPCにインターネットへ出る為の「インターネットゲートウェイ」がアタッチされ、ルートテーブルにインターネットに直接つながるサブネットのこと

 

プライベートサブネット

  • インターネットゲートウェイが付与されておらず、インターネットからはアクセスできないサブネット。
    プライベートサブネットにする場合はインターネットゲートウェイを付与してはいけない。
  • 「NATゲートウェイ」を付与すると、プライベートサブネットからインターネットには通信が出来るようになる。

 

NATゲートウェイ

  • プライベートサブネットの場合はインターネット接続出来ないので、yumやWindows Updateといった通信も出来ない。
    解決として、
    NATゲートウェイを付与すると、プライベートサブネットからインターネットに通信を取りに行けるようになる。
  • インターネット側からNATゲートウェイには通信出来ない
  • 接続先でIPアドレス制限を行うために、インターネットへ出ていく際のグローバルIPアドレスを固定化したい場合

 

ルートテーブルの例

  • 0.0.0.0/0 -> NATゲートウェイID
    すべての通信をNATゲートウェイに通信させる
  • 192.168.0.0/24 VGW ID
    192.168.0.0/24への通信はVGP(Virtual Private Gateway)へ通信させる
  • 10.0.0.0/16など自信のCIDR -> local
    送信先が同一セグメントなら、同一セグメント内に通信させる

 

VPCエンドポイント

DynamoデータベースやEC2などのアクセスはインターネットを経由する必要があったが、VPCエンドポイントを使用することで、AWSの一部のサービスでプライベート通信が可能になった。

 

VPCピアリング接続

異なるVPC間をプライベート接続するサービス

VPC同士は通常独立したプライベートネットワーク同士なので直接通信を行えないが、VPCピアリング接続を利用することで、VPC同士がインターネットを経由せずにAWSのプライベートネットワーク内で直接通信することが出来る

 

 

Elastic IP

  • Elastic IPを利用するには固定のグローバルIPを確保していることが必要。
  • インスタンスだけでなく、NATゲートウェイにも付与できる
  • インスタンスに紐づいている場合は課金されない

 

ネットワークセキュリティ

 

セキュリティグループ

AWSのファイアウォール。

  • セキュリティグループはENI(Elastic Network Interface)に付与される。
  • EC2インスタンスやNATゲートウェイはENIがあり必ず付与される
  • 許可の設定は出来るが、拒否の設定は出来ない
  • 重複設定は緩いほうが採用される
  • セキュリティグループIDを指定することで制限が出来る
    EC2とRDSの通信などでよく使う
  • インバウンド、アウトバウンド個別に設定が可能
  • タグベースの設定は出来ない

 

ネットワークACL

サブネットに対してのアクセス制御。

  • 拒否設定が出来るので、特定のIPアドレスから攻撃を受けた場合にアクセスを拒否できる。
  • ACLはステートレスなのでセキュリティグループと異なり、
    通信を行う場合にリクエストとレスポンスで両方の許可を行う必要がある。
  • デフォルトはすべて許可
  • インバウンド・アウトバウンド両方で許可、拒否を設定できる

 

ネットワークACLとセキュリティグループの違い

ネットワークACL セキュリティグループ
対象 サブネット ENI
制限 許可・拒否 許可のみ
ストートレス、ステートフル ステートレス ステートフル

 

 

プライベート通信

 

Direct Connect

オンプレミスなど自社のネットワーク環境とAWSのVPCを専用線で接続するサービス

  • 自社のオフィスとVPC上のActive Directoryと接続が可能
  • 専用線で接続しているので安定した通信品質がある
  • 自社データセンターとAWSをセキュアに接続できる

似たサービスとしてVPNがあるが、安定した品質やトラフィックによる従量課金が気になる場合はDirect Connectを検討する。

 

VPN

  • バーチャルプライベートゲートウェイを利用したサイト間をつなぐことが出来る。
  • インターネットを利用するのでDirect Connectと比較すると通信品質が落ちる
  • 通信品質をあまり気にしないで済む場合に使える
    プライベートサブネット接続用や管理・メンテナンス経路

 

VPCピアリング

  • VPC同士をセキュアに通信する場合に利用する。
  • VPCピアリングを利用することで、インターネットを介せずにVPC同士でプライベートなトラフィックの通信が出来る。
  • VPC間で仮想ケーブルでつなげるイメージ
  • 別VPCのAWSサービスに直接接続させるPrivate Linkやリージョン間でのピアリングも可能になっている

 

DNS

名前解決のサービス

Route53

AWSを利用する場合のDNSはRoute53を利用したほうがサービスの連携がスムーズで良い。

  • SLA100%で可用性が高い
  • EC2やRDS,ALBなどDNS名で利用できる
  • 加重ルーティング(Weighted)
    複数のエンドポイントに60:40などトラフィックを分散させることが可能。
  • レイテンシルーティング
    複数リージョンでサービス展開している時に、遅延が一番小さいリージョンにルーティングする
  • 位置情報ルーティング(Geolocation)
    クライアントの位置情報を元にエンドポイントを変える。
    地域毎にローカライズされた情報を配信する場合に有効

 

CDN(Content Delivery Network)

世界中に分散配置されたサーバ群にコンテンツを配信し、大規模なアクセス処理を行い高速にコンテンツを配信することを可能にする。

 

  • ユーザのアクセスに近いサーバにルーティングし配信を高速化
  • サーバ側でコンテンツのキャッシュを行い、オリジンの負荷を軽減する
  • エッジに配置されたコンテンツのキャッシュのクリアには1分以上かかる

 

AWSでのCDNの一般的な利用例
  • 静的なコンテンツの配信
    CloudFront + S3
  • お問合せなどの動的なページ処理
    EC2

AWSのCDNではCloudFrontがある

 

CloudFront

  • サーバレス。
  • 高可用性、高パフォーマンス、低レイテンシーなネットワークが用意されている。
  • オリジンとしてS3, EC2, ELBなどを指定出来る。

 

オリジン?

CloudFrontへキャッシュするコンテンツの提供元

 

SSLによる通信暗号化

SSL証明書を利用した通信暗号化を行える

 

署名付きURL

一定時間だけアクセスを許可するためのURLを発行し、URLを通知した限定ユーザのみに公開を行える。

 

カスタムエラーページ

オリジンからエラーコードが返された時に、あらかじめ設定したエラーページを表示することが出来る

 

地域制限(地理的ブロッキング)

CloudFrontへ接続するユーザの地域情報に基づいて、アクセスを許可または拒否することが出来る

 

ストリーミング配信

WEBサービスのコンテンツ配信以外に、映像や音声のストリーミング配信も行える

 

 

コンピューティング

 

EC2インスタンス

 

EC2

  • AWSにおける仮想サーバ
  • インスタンスタイプを選べる

インスタンスタイプ

あくまで私見
  • 最小インスタンスとしてt2.small
  • 汎用インスタンスとしてC4.xlarge

これがトラブルが起きにくい、他は要件や負荷に合わせてインスタンスタイプを合わせていく。

 

特徴
  • 汎用 T系
    開発で利用する。
    一時的な高付加時にCPUクレジットを利用したバーストが特徴
  • 汎用 M系
    CPU, メモリ, ネットワークとバランスが良い
    個人的にはあまり使わない
  • コンピューティング最適化 C系
    CPU負荷の高い使用。
    個人的にこれが汎用、C4.xlargeが汎用
  • メモリ最適化 R系
    大量のメモリが必要なアプリで利用
  • メモリ最適化 X系
    メモリ最大容量が4TBクラス!
  • 高速コンピューティング P系
    画像処理や機械学習用途
  • ストレージ最適化 H, I , D系
    データウェアハウス、NoSQLなどストレージアクセス負荷の高い用途

 

インスタンスメタデータ

EC2インスタンス自身に関するデータで、実行中のインスタンスを設定、管理するために利用される。

  • インスタンスID
  • プライベートIPv4アドレス
  • パブリックIPv4アドレス
  • ローカルホスト名
  • 公開鍵

 

 

AMI

仮想イメージ。EC2の起動に必要な情報をまとめたもの。

 

パブリックAMI

作成したAMIを自由に公開できる、パブリックAMIを利用する際は作成元に気を付ける。AWSマーケットプレイス以外のAMIは利用しない方が無難です。

 

自分で作成したAMI

ゴールデンイメージとして利用して水平展開したり出来ます。バックアップ用途としても使えます。

 

ユーザデータ

起動と同時にOS上で何らかの処理を実行させたい場合に利用する。

  • 監視エージェントをインストールする
  • 環境変数の設定
  • GitHubからアプリケーションをダウンロード展開し、サービスを起動
  • S3やKMSからデータベース接続情報などお機密情報を取得しアプリケーションに設定する
    // 古い方法。昨今ではパラメータストアなどの簡易ストレージで暗号化した状態で受け渡すことを推奨。

起動時の処理として、ユーザデータが良いのか?AMIに埋め込むのか?選択する。

 

タグ

任意の属性情報を付与するタグによって、Key-Value型で設定できる。

  • タグから搾りこみ、グループ化を行う
  • AWSリソースの選択

絞り込み要素として利用する、使いこなそう!

 

 

プレイスメントグループ

  • EC2インスタンスをグループ化し、物理的になるべく近いインスタンスとして起動する。
  • 通信速度を向上させる仕組み

 

EC2購入オプションによるコスト最適化

 

リザーブドインスタンス

  • 事前に利用する権利を購入し大幅割引お受けれる機能
    期間が年単位。
    // AWSはすごい勢いで安くなってるからリザーブドで購入してしまうのはリスクがある。

 

スポットインスタンス

  • AWS上で余っているEC2の余剰リソースを大幅割引(最大90%オフ)で利用できる機能。
  • 入札価格がうわまった場合に強制的に停止させられるリスクがある
  • 停止しても問題ないよう工夫が必要
  • オートスケールの最低限の台数をオンデマンドインスタンスで常時稼働分を確保する、負荷に応じて増加する台数はスポットインスタンスを利用する

需要に応じて増加するインスタンスにスポットインスタンスを利用する。

 

Lambda

サーバレス型サービスで関数単位で処理を実行する。

  • サーバのプロビジョニングや管理が不要
  • コードの実行時間で課金される
  • 実行されるごとにコードが呼び出され、自動的に並列でスケールし処理される
    CPUやメモリのことを考えなくて良い。
  • イベントをトリガーに実行
    S3にファイルがプットされた時、SNSの通知があった時、スケジュールで設定された日時などをトリガーに出来る
  • APIゲートウェイとの組み合わせが可能
    APIゲートウェイとLambdaは処理時間のみの課金かつ自動スケールしてくれるので、時間帯によってアクセス数が激しい、特別な日だけアクセス数が激増するなどのサイトで非常に有効

向いている場面

  • リクエストの頻度が少ないが、常時待ち受ける必要のある処理やサービス
  • リクエストの需要に応じてコストを可能な限り最適化したい場合

 

向いていないケース

  • 処理時間が長い処理
    1回の実行時間が300秒(5分)という制限がある、最大900秒に伸びたが長い処理、頻繁な処理には向いていない。
  • 24時間絶えずリクエストがあるWEBサービス
    EC2を利用した方が安い

 

ロギング

Lambda関数の処理結果はCloudWatch Logsに保存される

 

ExecutionRole

LambdaにアタッチされたIAMロール

 

その他のコンピューティングサービス

 

Amazon Elastic MapReduce(EMR)

大量のデータを迅速、容易に、かつコスト効果よく処理するためのWEBサービス

大規模なデータを蓄積し分析する技術としてHadoopやSparkなど分散処理があるが、EMRはこれらの主要な分散処理環境を構築でき、それを簡単に利用できる

 

Amazon Elastic Container Service(ECS)

Dockerのコンテナオーケストレーションサービス

 

VM Import/Export

  • オンプレミスのVMwareのマシンイメージをEC2インスタンスにインポート出来るサービス
  • VM ImportされたEC2インスタンスをエクスポートしてオンプレミスでまた利用することも出来る

 

 

 

ストレージ

S3(Amazon Simple Storage Service)

高い耐久性を誇るストレージサービス

  • SLA 0.99999999999(イレブンナイン)
  • 1ファイル最大5TB
  • 保存容量が実質無制限
  • 月額が安価 0.025/1GB
  • WEB静的コンテンツ配信対応
  • クロスリージョンコピー機能
    リージョン間でデータを簡単に複製できる
  • 非推奨ながらEC2でマウントも出来るがAWS側として非推奨
    EFSを利用することが推奨されている

用途

  • 静的コンテンツを配信するWEBサーバにもなる
  • AnsibleやChefなどのコンフィグを保管して、OS起動時に自動取得し実行させる
  • データベース接続情報をS3に保管しOS起動時にS3から自動取得し環境変数へ設定する
  • ログ保管サーバ
  • バックアップやディザスタリカバリ
    ・バージョニングを有効化して世代管理が可能
    ・クロスリージョンで別リージョンにも複製可能

 

構成要素

  • バケット
    保管場所
  • オブジェクト
    データ保温体、1オブジェクト5TBまで
  • キー
    オブジェクトの格納URLパス。
    “バケット名+オブジェクト名+バージョン”が一意になっている

 

S3のストレージクラス、Glacierによるコスト最適化

 

ストレージクラス

単体でも安いS3に対してさらにコストを最適化できるようにオプションやサービス連携があります。これらをストレージクラスと言います。

低頻度アクセス

S3の「ライフサイクルポリシー」を利用することで、ストレージ間のオブジェクト移行を自動的に実行できる。

S3標準IA(低頻度アクセス)
  • 「S3標準」より保管コストが安いが、取り出し時に料金がかかることが特徴
  • バックアップ、長期保存、災害対策のデータストアとして
S3 1ゾーンIA(低頻度アクセス)

S3標準クラスのアベイラビリティを必要としていない、かつアクセス頻度は低頻度」オンプレミスのセカンダリバックアップ、S3のクロスリージョンレプリケーションで利用する。

 

Glacierによるアーカイブ

ストレージクラスの中で保管コストが最も低いストレージサービス。

法律上数年以上保持することが求められる監査データの保管など

 

用途
  • アクセスはほぼないが、コンプライアンス上アーカイブが必要で、最も安価に保存したい
  • 規約やコンプライアンスによって、数年間の長期保存が必要となるデータの保存

 

S3のセキュリティ

 

セキュリティ

世界中のすべての規制機関によるコンプライアンス要件を満たしている

 

バケットポリシー

  • S3バケットに対するアクセス権限を設定する機能、JSONベースで定義する
  • GUIのポリシージェネレータで設定が可能

 

暗号化

 

クライアントサイト暗号化

暗号化、複合化をクライアントサイド(ユーザ)に任せる

 

鍵の管理 説明
クライアント 鍵の管理はクライアントサイド。暗号化、複合化を行う為にコードを書く必要あり
KMS 鍵の管理はKMS。CloudTrailで監査も可能。暗号化、複合化を行う為にコードを書く必要あり

 

サーバサイド暗号化

暗号化、複合化をサーバサイド(AWS)に任せる

 

鍵の管理 説明
クライアント 鍵の管理はクライアントサイド。暗号化、複合化はサーバ側(AWS)が実施
AWS(KMS) 鍵の管理はKMS。CloudTrailで監査も可能。
AWS(S3) 鍵の管理はAWS。S3で鍵の作成、暗号化、複合化を実施する

 

ロギング

  • いつ、誰が、何をしたのかを記録する
  • ログが改ざんされていないことを保証することも重要
    S3ではすべての操作履歴をCloudTrailで記録出来る

ただし、大量にGet/Putを行う使い方をしていると、CloudTrailの課金が多くなる。

何を記録したいのか、何を守りたいのか適切に記録するように設定する。

 

セキュアなファイルを配置する際のアクセス方法

S3にコンフィグファイル、秘密情報、データファイルなどを配置し大量配布することが出来る。

注意点として、S3にアクセス出来る人、システムを絞ることが重要

 

推奨される方法
  • S3のアクセス権限が付与されたIAMロールをEC2に付与し、S3にアクセスする
    // IAMロールを利用することでEC2にアクセスキーをハードコーディングする必要がない

 

 

S3 WEBホスティング

WEBの静的コンテンツ配信機能

  • サーバレス
    耐久性、パフォーマンス、可用性最高で負荷によってダウンしない

 

EBSのボリュームタイプ

 

特性を把握してワークロードによるコスト最適化を行おう!

  • EBSマグネティック
    旧世代
    データへのアクセス頻度が低い
  • 汎用SSD
    コストパフォーマンスが優れる汎用SSDボリューム
    $0.12/1GB
  • プロビジョンドIOPS SSD
    低レイテンシーor高スループットで高パフォーマンスSSDボリューム
    $0.142/GB
  • スループット最適化HDD
    アクセス頻度が高いワークロード、低コストのHDD
    $0.054/1GB
  • Cold HDD
    アクセス頻度の低いワークロード、低コストのHDD
    $0.03/1GB

 

EFS(Elastic File System)

フルマネージドのNFS用共用ストレージ

 

EFSの特徴

  • EFSは使った分だけ課金
  • ペタバイトまで対応
  • 保存容量に応じてスループット、IOPS性能向上
  • 数千の同時接続サポート
  • 複数のアベイラビリティゾーンに複製、保存され高耐久、高可用性

 

EFSの用途

  • ビッグデータ分析やメディア処理
    高スループット、書き込み後の読み取り整合性、低レイテンシーを必要とするビッグデータアプリケーション
  • コンテンツ管理とWEB配信
    コンテンツ管理システム用ファイルシステム
  • ホームディレクトリ
    組織全体のユーザがアクセス可能なファイルシステムを作成し、ユーザ・グループのファイルレベル、またはディレクトリレベルのアクセス許可
  • 複数のEC2からアクセス可能なコンテンツ共有サーバ

 

料金比較

  • EBS $0.12/GB
  • EFS $0.36/GB

EBSと比べるとEFSは3倍コストがかかる

 

 

その他のストレージサービス

 

インスタンスストア(エフェメラルディスク)

特定のインスタンスタイプで利用出来る、ホストコンピュータのローカル領域を使用しているので高パフォーマンスだが、揮発性のディスクなのでEC2停止時にデータが消失してしまうので注意が必要

 

Amazon Storage Gateway(SGW)
  • S3へNFS, SMB, iSCSIといった標準プロトコルでアクセス出来るサービス
  • EC2インスタンスだけでなくオンプレミスサーバにS3をマウントして利用することも可能

 

キャッシュ型ボリュームゲートウェイ

データはS3に格納するが、アクセス頻度の高いデータはローカルにキャッシュすることで高速アクセスを実現する。インターフェイスにiSCSIを利用。

 

保管型ボリュームゲートウェイ

データをスナップショットしてS3に保存する。インターフェイスにiSCSIを利用。

テープボリュームゲートウェイ

物理テープ装置の代替としてデータをS3(Glacier)に格納。インターフェイスにiSCSIを利用。

 

ファイルゲートウェイ

データをS3に直接オブジェクトとして格納。インターフェイスにNFSを利用。

 

 

 

データベース

 

データベースサービス

用途にあわせて適切にデータベースサービスを選択する

  • RDS
    ・拡張可能なリレーショナルデータベース
    ・用途:トランザクション処理が必要な場合など
  • DynamoDB
    ・シームレスな拡張性、高速なNoSQL
    DynamoDBにもトランザクション機能が実装された
    ・用途:ユーザ属性、行動履歴ログ、メタデータの保存
  • Redshift
    ・ペタバイト規模に拡張できる高速なデータウェアハウス
    ・用途:全社横断的なデータ分析基盤など
  • ElastiCache
    ・拡張が容易なインメモリキャッシュ
    ・用途:セッション情報、クエリ結果のキャッシュ(オブジェクトキャッシュ)

 

選び方

  • 汎用性が高いのはRDS
  • 低レイテンシーやキャッシュはDynamoDB, ElastiCache

 

 

 

 

RDS

フルマネージドなリレーションデータベースサービス

特徴

  • Oracle, SQL Server, MySQL, PostgreSQLなどのデプロイが可能
  • AZレベルでの冗長化、リードレプリカが作成可能
  • GUIでパッチ適用が可能
  • ポイントタイムリカバリでデフォルトで5分前の状態に復元可能
  • インスタンスタイプ変更でスケールアップが可能

 

注意点

  • オートスケールは出来ない
    自分で判断してスケールを手動で行う必要がある
  • スケールアップ時のダウンタイム発生
    ダウンタイムを少なくしたい場合は
    Auroraを選択するか,
    DynamoDBのようなオートスケール可能なDBを選択
  • マルチマスタは組めない

 

要注意

  • 標準設定の場合、1日1回自動バックアップされる。
    データベースとトランザクションログが取得される
    ただし、RDSの削除と同時に自動バックアップされたデータも削除される。
    自動バックアップ以外に手動で必ずバックアップを行っておくこと
  • RDSでは5分毎にトランザクションログを保存している、最新のデータを復元すると過去5分以内の状態にデータベースインスタンスを戻すことが出来る
  • 必ずMulti-AZで利用する
    バックアップやパッチの適用で大きなダウンタイムが発生する、
    Multi-AZにすることでこれを回避出来る

 

RDSの復元方法

  • 通常
    スナップショットからデータベースインスタンスを復元
  • ポイントインタイムリカバリ
    バックアップのデータベースとトランザクションログが残っている範囲内の特定の日時時点にデータを復元

 

パッチ適用の管理負荷軽減

曜日や時間帯をメンテナンスウィンドウで指定するだけでAWSが自動でパッチをあててくれる

 

 

 

リードレプリカ

読み取り専用データベース。負荷分散に役立つ

 

用途

  • よくあるWEBの3層構造
    ELB → EC2 → RDS

この時にRDSはインターネットからアクセス出来ないサブネットに設置して、EC2経由でしかアクセスできないようにするのが一般的

 

 

Aurora

  • エンタープライズレベルの高可用性
  • 低コスト
  • ストレージが自動拡張 64TBまで
    // RDSは容量を確保する必要がある
  • 3AZに2つずつ、計6つのデータコピーを保持できる
  • リードレプリカがある場合は1分程度でフェイルオーバが可能
  • クエリ並列度が高い。データサイズが大きいユースケースで高パフォーマンス
  • ゼロダウンタイムパッチ
    アップグレードの際、再起動を必要としない

 

 

DynamoDB

オートスケールするフルマネージドNoSQL。KVSとして高パフォーマンス

 

特徴

  • フルマネージド型NoSQL
  • 低レイテンシー
  • シンプルAPI
  • ストレージ容量制限なし
  • スループットキャパティの割り当てが必要
  • その他の機能
    オートスケール, DAX, TTLなど

 

スループットキャパシティ

テーブル毎に読み込み(Read)、書き込み(Write)に対しスループットキャパシティを割り当てる必要がある

  • Readが多くWriteが少ない
    → Read:1000, Write:100
  • Readが少なくWriteが多い
    →Read:100, Write:1000

 

キャパシティユニット
  • 読み込み(Read)の1ユニット
    最大4Kバイトのデータを1秒に一回読み込み可能
  • 書き込み(Write)の1ユニット
    最大1Kバイトのデータを1秒に1回書き込み可能

 

用途

  • KVS
  • ログ、行動履歴
  • モバイルアプリのバックエンド
  • バッチ処理の状態管理
  • メタデータストア

 

 

ElastiCache

フルマネージド型インメモリデータストア。データベースのキャッシュ(オブジェクトキャッシュ)としてのよく利用される

 

特徴

  • Redis, Memcachedが利用出来る
  • AZレベルの冗長化、リードレプリカ
  • バックアップやリストアもかんたん

 

用途

  • セッション管理
  • オブジェクトキャッシュ
  • ストリームデータ分析
  • メタデータストア

 

Redshift

ペタバイトスケールのデータウェアハウスサービス。

手動でのスケールイン、スケールアウトが必要

  • PostgreSQLをベースとしたデータウェアハウスに特化した高速RDB
  • ペタバイト級までスケール
    ・ノードを増やしてパフォーマンス向上
    ・自分でパフォーマンス調整必要(オートスケールしない)
  • フルマネージド型
  • データウェアハウスに適したカラム型データベース

 

 

セキュアな複数階層アプリケーション

 

複数階層サブネット

パブリックサブネット、プライベートサブネットを作成し、複数の階層を持つサブネットを構成するのが一般的構成

 

メリット

  • アクセスコントロールがサブネット単位に出来るのでセキュリティ管理が容易になる
  • インターネットから到達不可能な位置にDBなどを配置出来る
  • ネットワークACLでサブネットでアクセス拒否が出来る

 

階層パターン

 

1階層サブネット

サブネット1つで構成したパターン。

すべてのサーバがネットワーク的にインターネットからアクセス可能なサブネットに配置される

セキュリティグループがあるが、すべてのサーバインターネットからアクセス可能になるのでセキュアではない。

 

2階層サブネット

パブリックサブネット、プライベートサブネットで配置した構成

  • パブリックサブネット:NATゲートウェイ+WEBサーバ
  • プライベートサブネット:DBサーバ
メリット
  • 一部のサーバをインターネットからのアクセスから出来ないように出来るのでセキュアな構成を出来る
  • サブネットの構成がシンプル

 

3階層サブネット

鉄板構成

ロードバランサ → WEBサーバ → DBサーバ

  • パブリックサブネット:ロードバランサ、踏み台用EC2サーバ
  • プライベートサブネット1:WEBサーバ
  • プライベートサブネット2:DBサーバ

WEB, DBに直接アクセス出来なくなるのでセキュアになる。

管理者は管理したい時に踏み台用EC2サーバを起動し、WEBサーバ/DBサーバにアクセスを行う

踏み台経由でしか、WEBサーバ・DBサーバにアクセス出来ないのでセキュリティがあがる。

 

セキュリティ面でのメリット

パブリックサブネット・プライベートサブネット

パブリックサブネット、プライベートサブネットを使い分けることでセキュリティ上柔軟なネットワークが作れる。

 

NATゲートウェイ

  • プライベートサブネットでyumやWindows Updateといった、プライベートサブネットからインターネットへ向けた通信を可能にする。
  • プライベートサブネットに設置する

 

VPCエンドポイント

S3, DynamoDBなど特定のAWSリソースにインターネット経由でなく、AWSネットワークを経由してセキュアかつ高速にアクセスを可能にする機能

 

踏み台(Bastion)

  • プライベートネットワークに配置したサーバへの接続方法に使う。
  • セキュリティグループでIPアドレスでアクセス制御したり、利用する時だけ起動させることにセキュアに管理が出来る

 

VPN/Direct Connect

踏み台は脆弱性に問題があった時にインシデントが発生する可能性がある。

VPN/Direct Connectを利用してプライベートサブネットい接続することで、踏み台なしでセキュアに接続が可能

 

セキュリティグループの絞り方

  • IPアドレスでの制御
  • セキュリティグループIDでの制御

 

高可用性構成

 

ロードバランサ

アベイラビリティゾーンをまたいでバランシング出来る

 

定番構成

Multi-AZでバランシングすることで、1つのアベイラビリティゾーンがダウンしてもサービスを継続出来る

 

注意

  • ロードバランサはCNAMEを利用してドメインと紐づけること

 

ELB

  • ELBはインターナル向けにも利用出来る

 

SSL Termination
  • ELB側でSSLを受信し、EC2側は80番で通信するのでEC2側の負荷を軽減することが出来る
スティッキーセッション
  • ELB側でCookieを保存して一定時間同じEC2にクライアントのアクセスを向ける機能

 

CLB

  • ALB, NLBの利用が推奨される

 

ALB

CLBが以前は主流だったが、現在はALBの利用が推奨される

 

コンテントベースルーティング
  • ホストベースルーティング
    様々なドメインを1台のロードバランサで利用出来る
  • パスベースルーティング
    URLのパスベースで振り分けが出来る
注意
  • TCPの負荷分散は出来ない

 

 

NLB

  • TCPの負荷分散に特化したロードバランサ
  • 暖気不要で突発的な数百万リクエスト、秒のリクエストを処理が可能
  • 高スループット、低レイテンシー
    ALB, CLBは突発的なアクセスにスケールアウトが追いつかないが、NLBならいきなりのアクセスでも捌くことが出来る
  • SSL Termination機能はない
    バックエンドのEC2側でSSLを担う必要がある
  • IPアドレスの指定が可能
    ALBはEC2インスタンスを指定することになるが、NLBはIPアドレスを指定できるのでオンプレのサーバをも指定できる。
  • 固定IPを付与できる
    Elastic IPも付与できる
  • Source IP/Portがターゲットまで保持される
    ALBと異なり、x-forwerded-forヘッダを参照する必要がない
  • 対応プロトコルはTCPのみ

 

ロードバランサの使い分け

  • ALB
    HTTP, HTTPSで利用
  • NLB
    TCP& Internal LBで利用
  • CLB
    VPCがない頃のAWS環境向け

 

 

オートスケール

  • 需要に応じてEC2インスタンスを自動的にスケールアウト、スケールインする
  • コスト最適化が可能
    必要な時に必要な分だけEC2インスタンスを起動が出来る

注意

  • 負荷の閾値に達し、スケールしたEC2が起動して利用出来るまでとして5分程度かかるので注意
  • データベースやファイルサーバへの用途は向いていない
  • テレビCMなど突発的な負荷には向いていない

 

 

スケーリングプラン

  • 動的スケーリング
    負荷に応じてスケールする。
    CloudWatchのメトリクスによって閾値が達したと検知して動的にスケールする
  • スケジュールベーススケーリング
    時間でスケールする台数を指定出来る。
    これによってピークの一時間前に台数を増やす、ピーク時刻が終われば減らすといったことが出来る

 

シンプルスケーリング

平均CPU負荷X%でEC2インスタンスが追加される

ステップスケーリング

例:均CPU負荷60%で2台追加、平均CPU負荷80%で更に2台追加

ターゲット追跡スケーリング

平均CPU負荷60%を維持する為に自動計算して、必要な台数をスケールする

 

最低台数と最大台数

オートスケールでは最低台数と最大台数を指定出来る

 

起動設定

Auto Scaling実行時に起動するEC2インスタンスの情報を定義する

  • 利用するAMI
  • インスタンスタイプ
  • セキュリティグループ
  • キーペアなど

 

ヘルスチェック

インスタンスが正常かどうかをヘルスチェックで確認を行う、応答がないとロードバランサの配下からはずされる。

 

インスタンスの初期化処理

オートスケールはAMIベースでEC2を起動する

その際にアプリケーションをどう配置するかがポイント

 

  • ゴールデンイメージ
    AMIにアプリケーションも含めてしまう
  • ユーザデータ
    起動時にデータをダウンロードしてくる、
    アプリケーションが必要なライブラリなどのインストールに時間がかかる

 

鉄板構成

言語やライブラリはAMIに組み込み、変更の多いソースコードはユーザデータで起動時にダウンロード、外部パラメータを渡す

 

ステートレスな実装

負荷が落ち着くとEC2インスタンスはスケールインして削除される。削除されて困らないように状態を持たないようにする。

 

急激なアクセスへの対応

  • オートスケールはスケールアウトしたEC2インスタンスが起動して利用するまで数分かかるので突発的な対応に向いていない。
  • 予測出来る場合はスケジュールベースポリシーで事前にEC2インスタンスを増やしておく、CloudFrontなどを利用して負荷を軽減しよう

 

オートスケーリングによる耐障害性設計

アベイラビリティゾーンレベルの障害でも、別のゾーンで自動復旧する

 

オートスケールとインスタンス購入オプションによるコスト最適化

オートスケールとリザーブドインスタンスやスポットインスタンスを組み合わせることでコスト最適化を行える

最低台数はオンデマンドインスタンスで、オートスケールはスポットインスタンスやリザーブドインスタンスで賄う

最低台数は停止リスクのないオンデマンドインスタンスを使用する

 

最適化

  • 最低必要な台数にリザーブドインスタンス
  • オートスケールで増える台数にオンデマンドインスタンスやスポットインスタンス

 

スポットインスタンスのデメリット
  • 価格変動によりインスタンスが起動しない場合がある
  • 確保した分が不要になった場合に結果的にオンデマンドインスタンスより高くなってしまう場合がある

 

 

Queueによる負荷分散と動的スケーリング

 

  • SQSのメッセージ数に応じてWorker(EC2)を動的にスケーリングすることで、ジョブの需要に応じてコスト最適化を実現
  • SQSのSend, Receiveメトリクスが一定量超えた場合にオートスケールによりEC2インスタンスをスケールアウトすることが出来る

 

データベースキャッシュによる負荷分散と高パフォーマンス

 

ElastiCache

  • クエリ結果をキャッシュすることでデータベースの負荷軽減を行うことが出来る
    DBのクエリキャッシュをすることでRead負荷を軽減出来る
  • データ更新後にキャッシュもクリアするようにする
  • データベースに極力仕事をさせないようにする

更新頻度の少ないデータや、参照頻度が多いデータのキャッシュに向いている

 

データベースの高可用性

 

RDSのMulti-AZ

アベイラビリティゾーンをまたいでマスターとスレーブを構成し、マスターで障害があった場合に自動的にスタンバイがマスターに切り替わり高可用性を実現する

 

フルマネージドデータベース

DynamoDBのようなフルマネージドデータベースは、負荷を気にせずに可用性といったことを気にすることなく利用出来ます。

 

モニタリング

 

CloudWatchによるモニタリング

 

  • CloudWatch
  • CloudWatch Logs
  • CloudWatch Events

 

CloudWatch

AWSの各種リソースを監視、モニタリングする機能

 

CloudWatch Logs

AWSの各種サービスのログやサーバ内の各種ログを保管、閲覧する機能

 

CloudWatch Events

AWSリソースに対するイベントをトリガーにアクションを実行出来る

 

  • EC2インスタンスがStoppedになった時にLambdaを利用してAMIを作成
  • コンソールに誰かがログインしたらSNS経由でメール通知
  • CronのようにスケジュールベースでEBS Snapshotを取得する

 

カスタムメトリクス

 

CloudWatchの標準機能

 

  • CPU関係
    CPU使用率、ロードアベレージ
  • ディスクの読み書き
  • ネットワークIn/Out
  • インスタンスステータス

注意

  • CloudWatchは標準機能ではハイパーバイザレベルのメトリクスしか取得出来ず、メモリやディスク容量を把握出来ない
  • メモリやディスク容量を把握する為にはCloudWatchエージェントをインストールする必要がある

 

アラーム

メトリクスの条件をトリガーにしてアクションを起こす機能

 

  • CPU使用率90%でメール送信
  • EC2インスタンスのステータスチェック失敗すると復元を行う
  • オートスケールをカスタムメトリクスのアラームで利用

 

 

その他の運用管理サービス

 

VPCフローログ

  • VPC内のネットワークインターフェイス間で行き来する通信の内容をキャプチャする
  • 意図しない通信がないか監査することが出来る

 

AWS Config

  • AWSサービスで管理されているリソースの構成変更を追跡するサービス
  • 例として、
    EC2インスタンスの作成、削除などの構成変更の履歴をログに取得できる

 

AWS Systems Manager

AWS内の様々なリソースの運用情報を可視化、および制御するサービス

CloudWatchやCloudTrail、AWS Configなどの情報とも連携し、統合的に収集したログなどを表示出来る

EC2インスタンスなど様々なAWSリソースに対する運用タスクの制御や自動化も行える

 

AWS Trusted Advisor

AWSベストプラクティスに基づいて、コスト最適化、セキュリティ、耐障害性、パフォーマンス、サービスの制限の5項目でユーザのAWS利用状況を査定してくれる

 

 

プロビジョニング

 

コードを用いたインフラの自動化

 

CloudFormation

このサービスを利用することでインフラのコード化が可能になり、同じ構成を再現できるようになる

  • 開発環境、ステージング、本番を統一出来る
  • CloudFormationのテンプレートを配布する
    ・無駄な構築作業をなくす
    ・高可用性やセキュリティ要件を満たす
  • 災害対策
    災害時に別リージョンで本番構成を再現し切り替えることが出来る

 

 

テンプレート
  • 設定ファイルを指し、このファイルにプロビジョニングしたいAWSリソースを記述する。
  • フォーマットはJSON, YAML

 

スタック
  • CloudFormationによってプロビジョニングされるAWSリソースの集合
  • プロビジョニングしてスタックを作成するのがCloudFormationの役割

 

 

 

 

 

プロビジョニングツール

 

Elastic Beanstalk

  • よくある定番構成の構築、アプリデプロイの自動化サービス
  • インフラ担当者がいなくてもWEB構築可能

複雑な構成では使いにくい

 

OptWorks

Chef/Puppetを利用してアプリケーションを構成、運用するための構成管理サービス

 

 

 

@see

  • AWS認定ソリューションアーキテクトアソシエイト合格教本
  • AWS認定ソリューションアーキテクトアソシエイト教科書

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)