予備知識レベル
私の知識レベルとしては、このような感じです。
- 2019年よりサーバサイド開発
- 下記のAWS関連の書籍を読んだ
- Amazon Web Services 基礎からのネットワーク&サーバー構築
- AWSをはじめよう
- 業務ではほぼAWSは触らない
- プライベートで開発したシステムをAWSでデプロイしたことはある
上に挙げた2冊のAWS書籍は、いろいろな方がおすすめしているのを見て、amazonでも評価が高かったので購入しました。どちらも予備知識がなくても読み進められるように丁寧に解説されていて、最初の1冊としては大正解だったと思っています。
今度はブログシステムをAWS上で動かすだけでなく、ストレージの使い分け、負荷分散の方法、オートスケーリングの構築方法などを学びたいと思い、掲題の書籍を購入しました。
感想
基板設計のベストプラクティスだけでなく、なぜそれがベストプラクティスなのかが丁寧に解説されていて、理屈がないと覚えられない自分にとっては大変ありがたかったです。
それまでAWSの認定資格には興味をもったことがなかったのですが、この本を通じて基板設計の重要さと面白さを実感して、挑戦してみたい気持ちになりました。ちなみに、2016年のアメリカの調査では、稼げるIT関連資格の1位が「AWS認定アソシエーションアーキテクト-アソシエイト」だったらしいです。
以降は、章ごとに感想を書いていきます。
※ 間違って理解している箇所などありましたら、ご指摘いただけると大変嬉しいです
リージョン選びとネットワークの設計
この本を読むまでは、VPCはインスタンスを起動するために必要な場所、という程度の理解でした。
VPCは仮想ネットワークのことですが、複数のアベイラビリティゾーンを横断することができます。これはオンプレミス環境でいえば、複数のデータセンタを横断するプライベートなネットワークを構築することに相当し、実はすごいことなんじゃないか、と認識が変わりました。
リージョンの選び方
リージョンの選び方については、「ユーザが日本に住んでいたら東京リージョンでしょ」と簡単に考えていましたが、社内規定などでデータ保管場所や方法に制限がないか、使用したいAWSのサービスや機能が東京リージョンにも導入されているかなど、事前に考えなければならないことがあることがわかりました。サービスの価格もリージョンによって異なるので、その点も注意するほうが良さそうです。
メインルートテーブルを直接編集しない理由
VPC内のサブネットからインターネットに接続できるようにするには、ルートテーブルと呼ばれるトラフィック経路の定義にインターゲットゲートウェイのルートを追加する必要があります。
VPCを作成すると、メインルートテーブルが自動で作成されますが、「インターネットゲートウェイのルートを追加する場合は新たにカスタムルートテーブルを作成する」とこれまで読んだ書籍に書かれていました。メインルートテーブルを使わず、なぜ新たにルートテーブルを作る必要があるのか、と疑問に思っていたのですが、これは事故防止のためらしいです。新たにサブネットを作成すると、自動的にメインルートテーブルが関連づけられるので、意図せずパブリックなサブネットになってしまうからです。
セキュリティグループとネットワークACLの違い
VPC内のアクセス制御には、セキュリティグループとネットワークACLの2つの方法があります。
これら2つともファイアウォールだと紹介されていました。ファイアウォールというと、インターネット経由で侵入する不正なアクセスから守るための防火壁、などと別のところで説明されていたのを何度か読みましたが、具体的な働きをようやく理解できたと感じました。
セキュリティグループ
- インスタンスごとのアクセス制御
- ステートフル
- インバウンドはデフォルトで遮断
- アウトバウンドはデフォルトで許可
ネットワークACL
- サブネットごとのアクセス制御
- ステートレス
- デフォルトで許可
ざっくりとですが、上記のような違いがあるらしいです。
ステートレスという言葉は、最初どういう意味かわかりませんでした。Webサーバに対して、ユーザのセッション情報などを保持しない、という意味で使われているのは見たことがありましたが、ステートレスなファイアウォールという表現は初めてでした。
ステートレスというのは、リクエストを受けた際に、ポート情報などの接続に関する情報を保持することを指すようです。これにより、たとえばインスタンスからリクエストを送信した場合、そのリクエストに対するレスポンスは確立済みの接続として扱われるので、インバウンドルールで制限されていたとしてもファイアウォールと通過できるようです。
セキュリティグループとネットワークACLの使い分けについては、正直よくわからなかったので、下記の記事を参考にしました。AWSサポートの方が書かれている記事です。
当該セグメントのインスタンスすべてに共通する通信だけを大きくネットワークACLで許可し、各インスタンスへのアクセスはセキュリティグループで細かく制限する、という方法によって、比較的安全で楽に運用できるかと思います。
セキュリティグループは、APサーバ用、DBサーバ用と用途ごとに作成しておくことが一般的らしいです。
たとえばAPサーバを追加したときは、APサーバ用のセキュリティグループを適用するだけで、特に設定を変更せずにDBサーバに接続できるようになるため便利なようです。
仮想マシンとオブジェクトストレージ
仮想マシンはEC2ですが、オブジェクトストレージという言葉は初耳でした。
この本では、EBSなどのブロックストレージとS3などのオブジェクトストレージについて解説されています。AWSのストレージサービスには、他にEFSなどのファイルストレージがあるのですが、それについては触れられていなかったと記憶しています。
EBSとS3の使い分け
EBSはElastic Block Storeの略なのでブロックストレージ、S3はオブジェクトストレージです。
ブロックストレージでは、データを複数のブロックと呼ばれる単位に分割して保存するため、ファイルの一部を変更する場合は当該ブロックだけを書き換えればよいため、更新が高速で、使用する帯域幅が少なく済むそうです。
オブジェクトストレージは、ファイルとメタデータを合わせたオブジェクトという単位でデータを扱うため、テキストファイルの1文字を変更するだけでも、ファイル全体の更新が必要になるようです。ブロックストレージよりも低速ですが、容量は無制限で従量課金制であるため、拡張に柔軟な点が利点といえそうです。
次のように使い分けると良いらしいです。
- EBS
- 更新頻度が高く、低遅延が求められるデータ
- EC2インスタンスのブートボリュームやDBデータ領域など
- S3
- 更新頻度が低く、増え続けるデータ
- 画像や動画、アプリケーションのログなど
コンテンツをS3に移動するメリット
S3を使用するメリットをまとめてみました。
- VPCから独立しているため、S3を使うことでEC2インスタンスのネットワーク負荷を抑えられる
- ネットワーク負荷を抑えた結果、Eより安価なインスタンスタイプに変更できる可能性がある
- 容量が実質的に無制限であるため、EBSのように上限を気にする必要がない
- 自動的に3つ以上のデータセンターに冗長化されるため、バックアップを取る必要がない
このように、S3を使用するメリットは多いので、使用できる場面があれば積極的に使用していきたいなと思いました。
インスタンスストアって何？
EC2インスタンスを起動すると、インスタンスストアと呼ばれるストレージが割り当てられるようです。これはインスタンスの料金に含まれ、選択したインスタンスタイプにより容量が決まるようです。
注意しなければならないと感じたのは、インスタンスストアに保存したデータは永続化されないという点です。障害などでインスタンスが削除されたりすると、インスタンスストアも同時に削除されます。そのため、永続化する必要のあるデータは、インスタンスの外付けストレージであるEBSに保存したほうが良さそうです。
インスタンスのバックアップの取り方
インスタンスのOSやアプリケーションのデータをどう保持しておくとよいのか、自分なりに整理してみます。
EBSにはスナップショットという機能があり、ある時点でのボリュームのバックアップが作成できます。このスナップショットからAMIを作成することができるため、同じソフトウェア構成のインスタンスを新たに追加することもできるようです。
異常のあるインスタンスの自動再起動
CloudWatchというAWSリソース監視用のサービスに、ヘルスチェックという機能があり、これを利用すればEC2インスタンスが正常に動作しているか1分ごとにチェックすることができるようです。
インスタンスに障害が起きた場合は、EC2 Auto Recoveryというサービスを利用して、問題のあるインスタンスを停止・再起動する処理を自動化することができます。これだけで、インスタンスの物理ホストが移動し、復旧することが可能なようです。
負荷分散とスケーリング
スケーリングという言葉は知っていましたが、スケールアウトとスケールアップが違う意味だということは初めて知りました。
スケールアウト（水平スケーリング）はクラウドと相性が良いスケーリングですが、アプリケーション設計の段階からスケールアウトを想定しておかなければならないため、押さえておきたいと思いました。
また、負荷分散の方法を知りたい、というのが、この本を購入した理由のひとつなので、詳しく解説されていて良かったです。
スケールアウトしやすい設計
個人的には、この本を読んで最も面白いと思った部分です。
高性能なマシンに変更するスケールアップ（垂直スケーリング）に対して、サーバの数を増やすことで負荷の増大に対処することをスケールアウト（水平スケーリング）というようです。
まず、サーバをステートレスにすることが、スケールアウトしやすい設計の基本のようです。セッション情報などはインスタンスに持たせず、Elastic CacheやDynamoDBなど外部で管理することで、サーバを増減させやすくなります。
データベースサーバーの場合は、お互いに同期させなければならないためにスケールアウトが難しいようです。RDSを使用している場合は、読み取り専用のデータベースとしてリードレプリカを別途作成することで、負荷を分散させることができます。負荷が増大したときは、リードレプリカについては台数を増やすことで、マスタDBについてはインスタンスタイプを高性能なものにスケールアップすることで対応するようです。
マルチAZ構成にしてDBインスタンスの可用性を高められる
WebサーバーやAPサーバーは、複数台のインスタンス構成にすることで可用性が高められることがわかりました。では、DBサーバーの可用性を高めるにはどうすればよいのだろう、という疑問の答えも書いてありました。
RDSにはマルチAZデプロイメントというオプションがあり、これを有効にすると、マスターDBの複製が他のアベイラビリティーゾーン（AZ）に作られます。新しく複製されたほうはスタンバイDBと呼ばれ、マスターDBに障害が起きた場合は、自動的にスタンバイDBにフェイルオーバーされます。
フェイルオーバーという言葉も知らなかったのですが、稼働中のシステムに障害が生じて停止した際に、自動的に待機システムに切り替える仕組みだそうです。スタンバイDBは名前の通り待機システムなので、リードレプリカのように読み込み性能を向上させる効果はないようです。
Auto Scalingでインスタンス数を自動で調整する
インスタンス数を増減する機能は、Auto Scalingというサービスによって提供されます。本を読むまえは、ロードバランサあたりにそういう機能があるのかと想像していましたが違いました。
Auto Scalingでは、いつ、どんなインスタンスを、どこに、どれくらい配置するかを事前に定義します。このうちの「いつ」の部分で、監視システムのCloud Watchアラームが使われます。また、何日の何時からキャンペーンを行う、というように事前にわかっている場合は、スケジュールに基づいてインスタンスを増減することも可能なようです。
Auto Scalingは可用性を高めるだけでなく、余分なリソースを持たなくて済むため、コスト削減にも役に立つらしいです。
疎結合
この疎結合という章の中に、SNSやSQSやLambdaの説明が書かれていました。
SNSは、たしかSimple Notification Serviceの略で、アプリケーションからメールを送信するために実際に使用したことがありました。最初に目次を見たときは、なぜこれが疎結合につながるのか、と疑問に思いました。
キューを挟むことで可用性と拡張性が高まる
Web・APサーバーがリクエストを受け取り、自身で処理する、という構成に、何も問題はないように自分には思えましたが、これは密結合となるようです。
これを疎結合にするには、Web・APサーバーがリクエストを受けた後、SNS経由でキューにジョブ実行のメッセージを送るようにします。キューは、これから実行する予定のジョブを蓄積して、非同期でひとつずつ処理できるようにする仕組みです。
ジョブごとにキューを作成し、さらに各キューに対してそれぞれ複数のEC2インスタンスを割り当てます。そうすることで、各キューの負荷に応じて個別にスケーリングすることが可能になります。こうした構成も疎結合と表現するようです。
Lambdaによる疎結合とは？
予備知識として、Lambdaはコードをサーバレスで実行するためのサービス、ということは知っていました。EC2インスタンスを起動して、さらにプログラム実行に必要なOSやソフトウェアをインストールする、という手順をスキップして、Lambdaではコードを用意するだけで実行できます。
自分の知識はその程度でしたので、Lambdaと疎結合がどう関係するのか想像できませんでした。
この本では、仮想マシンの台数が増えて運用保守が大変になる、という疎結合化のデメリットを解消するものとして、Lambdaが紹介されていました。
先述の例では、複数のキューそれぞれに複数のEC2インスタンスを割り当てていました。こうすることで可用性と拡張性は高まるのですが、各インスタンスのOSのアップデートやセキュリティパッチ当て、障害復旧などの手間がかかります。しかし、このEC2インスタンスをLambdaに置き換えれば、こうしたわずらわしさから解放されるという意味です。
Lambdaを使用してコードを実行すれば、実行環境の管理やスケーリングを自動化されます。また、EC2インスタンスはコードを実行したかどうかにかかわらず料金が発生しますが、Lambdaはコード実行に使用した時間に対してだけ料金が発生するため、大幅にコストを削減できるようです。
CDNとDNS
DNSについては、他のAWSの書籍でも説明されていたので、ドメイン名とIPアドレスを対応づけるためのサービス、という程度の理解はありました。デプロイしたアプリケーションに、独自ドメインでアクセスしたいときに利用しました。
CDNは、CSSフレームワークのBootstrapを利用するときに使ったことがありましたが、誰でも利用できるように公開されているファイル、という誤った認識をしていました。
Cloud Frontはコンテンツをキャッシュして高速に配信する仕組み
AWSにはCloud FrontというCDNサービスがあります。
CDNの働きを理解する際、S3バケットに置かれたコンテンツにアクセスする例がわかりやすかったです。CDNでは、世界中に設置されたデータセンターに、コンテンツのキャッシュを保存します。ユーザーのリクエストは、それらのデータセンターのうち最もレイテンシーの短いデータセンターにルーティングされます。
このとき、コンテンツを保持するS3バケットをオリジン、コンテンツのキャッシュを保持するデータセンターをエッジロケーションと呼ぶようです。
Route53はいろいろなルーティングを実現できる
さきほども書きましたが、デプロイしたアプリケーションに独自ドメインでアクセスするときに、AWSのDNSであるRoute53を使いました。ちなみに53は、DNSサーバが53番ポートで動作することに由来します。
Route53には、独自ドメインとIPアドレスを単純に対応づけるだけなく、次のようなルーティングも可能なようです。
- 加重ラウンドロビン：同一のDNSクエリに対し、トラフィックの5%だけを別のWebサーバーに流す、といった重み付けができる
- Latency Based Routing：エンドポイントごとの応答時間を常に把握して、リクエストを最速のエンドポイントにルーティングする
- 位置情報ルーティング：日本国外のユーザーからのリクエストは、英語コンテンツを提供するWebサーバーに流す、といった位置情報に基づくルーティング
こうした処理を、ルーティングのレイヤーで担うことができることを知らなかったので、感心しました。
セキュリティ
この章にはIAMやKMSの説明が書かれていました。
セキュリティのベストプラクティスは、与えるアクセス権限もユーザーの範囲も、必要最小限に絞り込むこと、と書いてありました。これは非常にわかりやすい説明ですが、IAMは自分にとっては多機能すぎて、実際に使うときに適切な設定ができるか不安になりました。
暗号鍵を管理するKMSというサービス
KMSというサービスが紹介されていたのですが、この本を読むまで知りませんでした。
Key Management Serviceの略で、安全に鍵を管理するためのサービスのようです。データを暗号化するためのデータキーと、そのデータキー自体を暗号化するマスターキーという概念があるようです。
ちゃんと理解できた自信がないので、これ以上は説明できません。
基板構築の自動化
この最後の章では、Infrastructure as Codeについて説明されていました。
といっても、ページ数はそれほど割かれておらず、概要がさくっと書かれているような印象を自分は受けました。Infrastructure as Codeと聞いて自分が連想するのはTerraformでしたが、この本ではAWSのサービスであるCloud Formationが紹介されていました。
まとめ
まとめ、という章が本の中にあるわけではなく、私個人の感想のまとめです。
一言でいえば、自分には最高の本でした。各サービスの説明があり、そのあとにベストプラクティスが紹介されている、という構成なのですが、どんな構成にするのがよいか自分で考えながら読むと、まるでミステリーを読んでいるようで本当に楽しかったです。
この本を読んでAWS認定資格に興味が出たので、新たに「AWS認定ソリューションアーキテクト[アソシエイト]」という本を購入して読んでみました。こちらはさらに網羅的に幅広い機能を説明されているような感じで、また試験で問われやすい部分を強調してあるので、試験対策には良いと思いました。
しかし、読んでいて楽しかったのは、圧倒的にこの「AmazonWebServicesエンタープライズ基盤設計の基本」です。「ハンズオンでAWS上にブログシステムを構築してみたけれど、他のリソースのことも知りたい、でも認定試験にはまだそれほど興味はない」という自分と同じような境遇の方がいましたら、この本はおすすめです。