🎉

【書評】『図解 Amazon Web Servicesの仕組みとサービスがたった1日でよくわかる』を読んだ

に公開
AWS
network
Cloud
container
infrastructure
idea

はじめに

一度 AWS について体系的に学んでおくかと思い、『図解 Amazon Web Servicesの仕組みとサービスがたった1日でよくわかる』を読みました。

https://www.sbcr.jp/product/4815612818/

読んでみて大正解でした。改めて AWS サービス全体を整理できました。業務で触っていた部分に関しては復習するとともに、そのサービスの背景や裏側についても知ることができました。AWS のセキュリティやマネジメントサービスなど、普段あまり触ることが少ないサービスについても理解を深めることができました。即座に業務で使用できるレベルには至りませんが、全体感を把握する上ではこの上ない良書であると感じました。

本を読んで理解した内容をアウトプットするとともに、筆者なりの感想を書いていこうと思います。割とポエミーです。また文章量が多く、個人的な書きやすさから言い切りの文章で書いています。

図は載せていません。書籍は図による解説がふんだんに行われていました。ぜひ書籍を購入し、この記事は事典的に活用してください。また、おそらく長すぎて読めないと思うので、その観点からもこの記事を事典的に活用することをおすすめします。

目次

Chapter1: Amazon Web Services の基礎知識

最初にクラウドや AWS に対する基本的な知識が紹介されていた。インフラの全体像や AWS の特徴を掴むことができる。

クラウドとオンプレミス

クラウドとは

  • データセンター
    • サーバーなどの機器を設置する施設
  • オンプレミス
    • 利用者が管理する施設内に、機器を設置して運用すること
      • 持ち家のようなもの
        • 自前で機器の購入・設置・設定・修理を行う
        • 自前で機器の構成を自由に組める
        • 初期費用は高いが、ランニングコストは安い
  • クラウド・クラウドコンピューティング
    • クラウド提供者が機器を用意し、仮想サーバーやアプリケーションを提供する
      • 賃貸住宅のようなもの
        • 提供者が機器の購入・設置・設定・修理を行う
        • 物理的な機器の構成は提供者が決める
        • 初期費用は安いが、ランニングコストは高い

そもそも「データセンター」という言葉を聞いたとき、「なんだそれは？データしか保存していないのか？そんな酔狂な場所が実在するのか？」という生半可な理解でいた。しかし、改めて「サーバーなどの機器を設置する施設」であると明示されることで、そうなんだなと納得することができた。DB も結局はサーバーなのだから、命名は「サーバーセンター」の方がわかりやすいと感じたが、何か歴史的な理由があるのだろうと考えている。

オンプレミスと対比してクラウドの利点が語られていた。筆者はオンプレミス環境を経験したことはない。しかし、サーバーの購入・設置・配線・設定が1台1台に必要であり、その作業が大変なことは容易に想像がつく。クラウドの登場により、利用者が物理的なメンテナンスから解放されたことは大きな価値だと感じる。

その反面、設計者を志す者として、安易にクラウド至上主義信者に陥りたくないとも感じた。新規開発ではクラウドが有利だと感じる。しかし、すでにオンプレミスの資産がある場合や、巨大なシステムであったり社内人材が物理機器の扱いに長けている場合は、オンプレミスを選択することもあると感じる。結局は目の前の個別の課題に対し、最適な解決策を出していくのだ。各々が直面している状況は千差万別だ。その基本を忘れないようにしたい。

仮想化とは

  • 仮想化
    • 1つのサーバー機器を、複数のサーバー機器のように動作させる技術のこと
    • ストレージやネットワーク機器も仮想化できる
  • 仮想サーバー
    • 1つのサーバー機器のように動作するプログラム
      • 仮想サーバーは、物理サーバーのコンピューターリソースを一部占有する
      • それぞれが独立したサーバーとして動作する
  • 物理サーバー
    • プログラムを動かしているサーバー機器

つまりは、1台のサーバーを複数人でシェアしたいのである。限りあるリソースを、限りなく効率的に使用したいのである。そのためには論理的に分割できると楽だ。物理的な物体を論理的な境界で分割することが仮想化である。筆者は門外漢であるが、それにしても仮想化技術の発展はすごいと感じる。なぜならば1つの OS の中に論理的な境界を引いて、それぞれを個別のサーバーのように扱うのは、たしかに夢があるけれど明らかに大変そうだなと...。それを実現したのはすごすぎる。

サーバーレスとは

  • プロビジョンド
    • 利用者のために特定のサーバーを提供する方式
      • サーバーが予め提供されており、稼働している
      • すぐに利用が可能
      • サーバーが稼働している時間に対して課金
  • サーバーレス
    • 利用者がサービスを利用するときだけサーバーを稼働させる方式
      • 要求に応じてサーバーを作成し、利用が終わるとサーバーを削除
      • サーバーの作成に多少の待ち時間が発生
      • サーバーが利用されていた時間に対して課金

「サーバーレス」という言葉を聞くたびに「何に対してのサーバーレス？結局は、そのプログラムはサーバー上で動いているんだよね？」と感じていた。書籍では「サーバー管理に対してのサーバーレス」であると紹介されていた。OS やミドルウェアを管理する必要がないのだと。今後の書籍の内容に出てくるが、サーバーレスの例としての EC2 と Lambda の対比がとても理解しやすかった。

クラウドの形態とは

  • パブリッククラウド
    • クラウドの機器を他の利用者と共有する
  • プライベートクラウド
    • クラウドの機器を利用者が占有する

この上なくわかりやすい。プライベートクラウドを持つ利点については理解しきれていなく、どこかでキャッチアップしたい。主に大企業が採用しうる選択肢であるという理解でいる。

クラウドの利用形態とは

  • SaaS (Software as a Service)
    • アプリケーションをサービスとして提供する方式
      • Gmail、Dropbox、Offce 365 など
  • PaaS (Platform as a Service)
    • アプリケーションを作るための部品をサービスとして提供する方式
    • サービス提供者が OS やミドルウェアを管理し、利用者には機能のみを解放する
      • AWS のマネージドサービス
        • RDS、DynamoDB、Lambda など
  • IaaS (Infrastructure as a Service)
    • アプリケーションを作るための部品をサービスとして提供する方式
    • 利用者にサーバーやネットワーク機能が提供され、設定や管理も行う
      • AWS の非マネージドサービス
        • EC2、VPC、EBS など

PaaS と IaaS の違いは厳密には理解しなくても良いと感じた。書籍を読む上で両者の理解度が影響することもない。

マネージドサービスと非マネージドサービスの概念は、どこに自由度があり、どこに自由度がないのかの理解に役立った。RDS や Lambda はサーバーの OS やミドルウェアを管理する余地はない。Lambda はその最たるものだ。EC2 や VPC はそうではない。それらの設定値を利用者が指定・管理することに価値があるのだ。特に書籍では EC2 がかなり自由度の高いサービスとして紹介されており、筆者の EC2 というサービスに対する理解が深まったと感じた。

AWS を理解する6つのポイント

責任共有モデル

  • AWS 側と利用者側の責任範囲
    • 利用者の責任
      • インフラの運用
    • AWS の責任
      • ハードウェアの管理

AWS が採用している 責任共有モデル について紹介されていた。詳細の理解は後回しにし、とりあえず「インフラをどのように運用し、どのような結果になるかは、自己責任ですよ」と理解した。余力があれば深掘りしたい。

グローバルなシステムの構築

  • リージョン
    • AWS のデータセンターの地域
      • 世界中にある
    • e.g. ap-northeast-1
  • アベイラビリティゾーン (AZ)
    • 1つ以上のデータセンターから構築されるインフラ単位
    • リージョン内に複数存在し、各 AZ は独立している
      • データセンター障害が発生しても、他の AZ でサービスを提供できる
      • 距離的にも設備的にもそれぞれが独立している
        • 電力源、ネットワークなど
    • e.g. ap-northeast-1a
  • AZ 名と AZ ID
    • AZ ID が同じ = 地理的に同じ場所の AZ
      • AZ 名
        • アベイラビリティゾーン (AZ) の名前
        • e.g. ap-northeast-1a (リージョン + アルファベット)
      • AZ ID
        • アベイラビリティゾーン (AZ) の ID
        • e.g. apne1-az1
      • AWS アカウント
        • AWS アカウントごとに、AZ 名は異なる AZ ID に割り当てられる
          • AWS リソースが各 AZ に分散するようにするため
          • AZ 名はAWS アカウントごとに異なり、動的である
      • 障害発生時
        • AZ ID を確認し、被害を受けているか判断する

AZ 名と AZ ID の理解に時間がかかった。構造を端的に表現した図が掲載されており、ぜひ書籍を参照されたい。

まず AZ ごとに個別の ID が付与されている。これは ID なので固定だ。次に「AWS 上に作成されるリソースを、どのように各 AZ に分散するか？」を考える。たとえば、みなが AZ に apne1-az1 を選択してしまうと、その AZ にリソースが集中してしまう。どのように回避するのば良いだろうか？答えとして「利用者に AZ ID を直接選択させず」、「利用者には AZ 名を選択させ」、そして「AWS アカウントごとに AZ ID と AZ 名の紐付けを変える」のである。

具体的に見てみよう。みなが AZ 名 ap-northeast-1a を選択したとする。一番上に表示されるし、序列が上だとなんとなく安心するからだ。でも問題ない。なぜなら、AZ 名 ap-northeast-1a にどの AZ ID が紐づくかは、AWS アカウントごとにランダムだからだ。みなが AZ 名 ap-northeast-1a を選択しても、勝手にリソースが各地の AZ に分散されていく。

この仕組みを理解したとき「マジか。」と感じた。今まで見ていた AZ 名 ap-northeast-1a が接続される先は、AWS アカウントごとに異なっていたのかと。また、こんな大胆なことを本当にやるのかと。筆者は AZ ID の存在を知らなかったし、「ここまでやるんだ！すごい！」と感じた。

しかし、考えてみると当然なのかもしれない。データベースシャーディングのセレブ問題と同じだ。あなたは SNS アプリケーションを開発しており、最近は巨大なデータ量に対するデータベースの性能劣化が悩みの種だった。データベースの性能劣化に対応するため、あなたはデータベースを4つのシャードに分割し、ユーザー ID を起点にして、データの登録先をランダムにシャードへ振り分けた。しかし、4つのシャードの内、たまたまジャスティン・ビーバーとレディー・ガガがすべて同じシャードに入ってしまったらどうだろう？彼らのフォロワー数は凄まじく、そのシャードが他のシャードと比べて優位に性能劣化するだろう。

AWS リソースの AZ 分散も構造は同じだ。事前に複数の AZ を用意していても、もし大企業のほとんどが同じ AZ を選択し、AWS リソースが特定の AZ に集中してしまったらどうだろう？AZ 間の運用のバランスが取れなくなり、その AZ だけサーバー追加の要求が桁違いに高くなるかもしれない。AWS は AWS リソースをランダムにシャーディングしているのだ。

注意点として、AZ の災害発生時に、AZ の特定には「AZ ID (e.g. apne1-az1)」を見なければいけない。AZ 名 (e.g. apnortheast-1a) に対して、AWS アカウントごとに紐づく AZ が異なるからだ。

従量課金

  • 「時間単位あたりの料金 × 使用時間」で利用料金が発生する
    • 多くのサービスは1時間あたりの料金が設定されている
    • コスト管理は難しい部分もあり 2-3節 で解説する

システムの増減が自由

  • サーバーの大きさ（CPU、メモリ量）を簡単に変更できる
    • ユーザーが増えたらサーバーを増やすなど、柔軟な対応が可能

障害を前提に考える

  • Design For Failure
    • 障害は必ず起こる前提で設計する
      • 複数の AZ にサーバーを配置する
      • AWS 側で自動的に複数の AZ に配置されるサービスもある
        • S3
          • 自動的に3つ以上の AZ にデータがコピーされる
  • 可用性
    • システムが継続して稼働できる能力

すべてを冗長化する。すべてを冗長化するのだ。サーバーを分散し、DB を分散し、そしてインフラが稼働するデータセンターすらも地理的に分散するのだ。あるデータセンターに障害が発生しても、別のデータセンターでサービス稼働を継続できる構成にするのだ。

疑問として、オンプレミス環境の場合はどうしていたのだろう？各地に複数のデータセンターを契約し、冗長化していたのだろうか？それだと余計に人員の移動コストや機器の管理コストがかかってしまう。地理的な分散をしやすいことはクラウドの大きな利点だと感じる。

設計のお手本フレームワーク

  • Well-Architected フレームワーク
    • AWS 社員や多くの業界の設計・構築の考え方が詰め込まれたもの
    • 6つの柱
      • 持続可能性
      • コスト最適化
      • パフォーマンス効率
      • 可用性
      • セキュリティ
      • 運用の優秀性

体系的なドキュメントとしては AWS Well-Architected フレームワーク が良さそうだ。流し見したところ、インフラのみならず運用面やビジネス目標の設定など、多岐にわたって言及されていた。ゆくゆくは時間を見つけて読み、記事化しよう。

AWS の提供するサービス

AWS サービスの分類

  • コンピューティング
    • 仮想サーバーを提供するサービス
      • アプリケーションをミドルウェアを動作させるための環境
      • EC2、ECS など
  • ストレージ
    • データを保管するサービス
      • 仮想ディスク、仮想ストレージ
      • EBS、S3 など
  • ネットワークとコンテンツ配信
    • ネットワーク、コンテンツ提供の機能を持つサービス
      • 仮想ネットワーク、DNS、CDN など
      • Route53、VPC、ELB など
  • データベース
    • 様々な形式のデータの整理・保管・検索・集計を可能にするサービス
      • RDB、KVS、列指向 DB など
      • RDB、DynamoDB など
  • セキュリティ、アイデンティティ
    • システムをサイバー攻撃から守るためのサービス
    • ログイン管理や認証を行うサービス

書籍でもこの構成で説明が進む。AWS ドキュメントではクラウドはコンピューティングと分かれているらしいが、書籍では統合されている。本質的にはどちらも仮想サーバーを提供するサービスであり、妥当な編成だと感じた。

AWS の導入事例と利用イメージ

ゲーム業界の事例

  • マリオカート ツアー
    • データベースに Amazon Aurora を採用
      • リリース時のアクセスに耐えるため、予測の3倍のクラスタを構築
        • Aurora インスタンス 1,200台
      • 大規模トラフィックに対しても安定したレスポンスを返し続けた
        • Aurora 全体の秒間クエリ数は最大30万
        • データ量は1ヶ月で30TB
  • ドラゴンクエストX
    • 写真撮影機能の要求増に AWS Lambda を採用
      • Lambda の導入
        • リクエスト数と処理時間
          • 1分間に18,000枚
          • 画像処理を十数秒で完了
        • 費用
          • オンプレと比較し1/20
      • 写真撮影機能
        • 写真を撮影すると、サーバー上で画像を加工してから、保管する
      • 課題と対策
        • 年数回のイベントのために、高価なサーバーを導入したくない
        • 理論上は無限にスケールできる Lambda を利用する
      • 状況
        • リクエスト数と処理時間
          • 大晦日のイベント
            • 1分間に6,000枚
            • ユーザーが写真を閲覧できるまでに最長4時間
          • 通常
            • 1分間に200〜300枚

他にもさまざまな業界の導入事例が紹介されていた。筆者は Web アプリケーションエンジニアであるため、具体的な性能面のイメージを掴みやすいゲーム業界の事例をまとめた。

Aurora はかなりスケールできるという感覚を掴めた。クラスター全体の秒間クエリ数が最大30万、途方もない数字だ。インスタンス数が 1,200台 というのもかなり多い。特にゲーム業界はトラフィックが桁違いだ。

AWS Lambda が意外とスケールできることに驚いた。自分はコールドスタートにばかり目がいってしまうが、一度インスタンスが起動されればスムーズに稼働するものなのだなと理解した。画像処理のように起点と処理内容が明確、それでいて時間がかかる処理はまさしく Lambda の十八番ではないだろうか。

AWS の学習方法

学習パスがまとめられておりかなりありがたい。正直、AWS サービスのドキュメントは機械翻訳でどうしても読みづらさを感じてしまうため、他の学習媒体を知ることができたのは大きかった。

AWS Skill Builder は一部有料サブスクリプションが必要ながら、良質な学習コンテンツが揃っていそうだ。長期休暇にまとめて受講するのも良いかもしれない。

Chapter2: Amazon Web Services の始め方

AWS の初歩的な概念や操作がまとめられている。筆者は一部 AWS に慣れてしまっており、かなり割愛した内容を掲載する。

AWS アカウント

  • 利用者固有のアカウント
  • メールアドレスが固有である必要がある

ユーザー

  • ルートユーザー
    • アカウント作成時に自動作成される
    • AWS アカウント全体の変更も可能な最上級のユーザー
  • IAM ユーザー
    • IAM で作成される、適切な権限を持つユーザー
    • 基本的にはルートユーザーを使用せず、IAM ユーザーで操作を行う

AWS サービスの操作

  • AWS マネジメントコンソール
    • Web ブラウザから操作
  • AWS CLI
    • コマンドから操作
  • AWS SDK
    • プログラムから操作

コスト管理

  • AWS Billing and Cost Management
    • Billing
      • 請求書
        • 各月のアカウントへの請求
      • Cost & Usage Reports
        • 請求をより詳細に分類したレポート
        • AWS サービスの使用状況のレポート
    • Cost Management
      • Cost Explorer
        • サービスごとにコストとリソース使用状況をグラフで可視化
      • Budgets
        • 利用サービスを監視し、予算を超えたらアラート発報
        • 設定予算ごとの状況確認、管理
  • コスト管理の方針
    • Cost Explorer で現状把握し、方針を立てる
    • Budgets で予算設定し、利用状況を監視する

コスト管理について、普段はあまり触らないものであり、概要が掴めただけでもありがたかった。定期的に確認するとともに、どのサービスがどれくらいのトラフィックで、どの程度の費用がかかるのか、コスト感を掴んでいきたいと感じた。

リージョン

  • グローバルなリージョンのメリット
    • 世界各地のユーザーからの通信遅延を削減できる
    • 法的要件で特定の国にシステム構築する場合、要件を満たせる
    • 災害などで特定リージョンが使用できなくなった場合、他のリージョンでシステムを稼働できる
  • リージョンごとの違い
    • 表示されるリソース
      • リージョンごとにリソースは分離されている
      • AWS マネジメントコンソールからリージョンを選択すると、そのリージョンのリソースのみ表示される
    • 国内で複数リージョン
      • アメリカと日本のみ
      • 日本のリージョン
        • 東京リージョン
          • 2011年3月に開設
        • 大阪リージョン
          • 2021年3月に開設
          • 利用できるサービスが東京リージョンより少ない

国内で複数リージョンが存在している国はアメリカと日本のみらしい。アメリカは経済規模は大きく、地理的にも広く、複数リージョンが必要なことの想像がつく。アメリカと日本以外では国内には単一リージョンしかないのには驚いた。多くの国では、リージョンは自国のものを1つ選択し、その中に AZ が複数あることが当たり前なのだなと。

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

サービスの基本となるサーバーを扱うサービスが紹介されている。

サーバーとは

  • サーバー
    • ネットワークを介して何かしらのサービスを提供するコンピューター
  • クライアント
    • サーバーが提供するサービスを利用するプログラム
  • 代表的なサーバー
    • Web サーバー
      • Web ページの表示に必要なデータを提供するサーバー
    • DB サーバー
      • システムが取り扱うデータ処理を担当するサーバー
    • メールサーバー
      • メールの送信・配送・受信を行うサーバー
  • サーバーの OS
    • Linux
      • 大元の Linux カーネルと、それぞれが開発した Linxu ディストリビューションがある
    • Windows Server
      • マイクロソフトからリリースされており、GUI 操作が可能である
  • サーバーの仮想化
    • 1つのハードウェア上に複数の OS を稼働させること
    • AWS でも EC2 などで利用されている

EC2 とは

  • EC2
    • 仮想サーバーを数分で作成できるサービス
      • OS はあらかじめインストールされている
      • CPU やメモリは利用者が選択できる
  • インスタンス
    • EC2 の仮想サーバーの単位
  • インスタンスの作成
    • AMI
      • インスタンスのマシンの設定
    • インスタンスタイプ
      • インスタンスのスペック
    • VPC
      • 配置するネットワーク
    • EBS
      • ストレージの容量
    • セキュリティグループ
      • アクセス許可設定
  • インスタンスへの接続
    • SSH
      • Linux
    • リモートデスクトップ
      • Windows Server
    • AWS System Manager
      • EC2 インスタンスの管理サービス
  • Amazon マシンイメージ (AMI)
    • OS やソフトウェア設定が入ったテンプレート
  • インスタンスタイプ
    • 仮想サーバーの性能
      • 名前のルール (m6.g.medium)
        • ファミリー (m)
          • 特徴ごとに用意されたグループ
          • メモリ重視や CPU 重視など
        • 世代 (6)
          • 数が大きいほど新しく高性能
        • 追加機能 (g)
          • タイプごとに様々
            • g
              • Graviton2 (CPU の名前)
            • n
              • ネットワーク強化
        • サイズ (medium)
          • サイズが大きいほど高性能
    • ファミリー
      • T 系
        • ベースラインの CPU 使用率を超えて利用可能
        • バーストが一定量を超えると制限がある
          • ベースライン以下の性能になったり
          • 追加課金が発生したり
      • M 系
        • 本番環境など、常時使用が見込まれる環境に適している
  • 購入方法
    • オンデマンドインスタンス
      • 利用時間とインスタンスタイプに応じて従量課金
    • リザーブドインスタンス
      • 1年間または3年間の料金を先払いして利用
        • オンデマンドと比較して最大72%割引
    • Saving Plans
      • 1年間または3年間の料金を先払いして利用
        • 2019年に登場
        • リザーブドインスタンスよりも柔軟であり、おすすめ
    • スポットインスタンス
      • ただし、予期せずインスタンスを停止される場合がある
        • 停止される2分前に通知される
        • 開発環境や、複数台で稼働されている場合に検討できる
      • AWS 上で利用していないリソースを活用
        • オンデマンドと比較して最大90%割引
  • 利用料金
    • 利用時間
      • インスタンスタイプ × インスタンスの利用時間に対して課金
      • サーバー停止中は料金は発生しない
    • データ通信
      • ネットワーク外部へのデータ通信に対して課金
      • インスタンス料金と比較して安価
    • ストレージ (EBS)
      • データを保存するストレージに対して課金
      • インスタンス料金と比較して安価

EC2 について体系的にまとめられている。特にサービスの特性として、OS は AWS 側で用意され、リソース(CPU やメモリ)を利用者が選択する構成であることは、改めて EC2 サービスに対する解像度が上がったと感じた。

インスタンスへの接続方法としてリモートデスクトップが使用できることを初めて知った。Windows Server 限定ではあるが、GUI 経由で操作することができる。そもそも Windows Server 自体の特徴が GUI 操作可であり、当たり前ではある。

購入方法について改めて整理できた。通常はオンデマンドインスタンスを選択することになるだろう。リザーブドインスタンスの上位互換として Saving Plans があり、前払い制ながら柔軟性も兼ね備えている。スポットインスタンスの利用どころは難しいが、個人利用であれば費用削減の効果が大きいだろう。

利用料金についても改めて整理できた。利用時間に対して従量課金される。インスタンス停止時は料金が発生しないが、商用プロダクトでは夜間のサーバー停止などの対応は難しいだろう。比較的安価だが、データ通信とストレージに対して費用が発生することも忘れずにいたい。データ通信の最適化は難しいと感じる。ストレージに対しては、過剰すぎる割り当ては避けたいところだ。

インスタンスサイズの決定をどのように行うべきか？は悩みどころであると感じた。戦略として、負荷増大に対してサーバーをスケールアップ(垂直)するのか、スケールアウト(水平)するのか、選択する必要がある。同じスループットを実現するにしても、小さいインスタンスサイズで複数インスタンスを構築する方法と、大きいインスタンスサイズで単一インスタンスを構築する方法がある。画像処理など重い処理を行う場合は、インスタンスタイプが大きい方が、1リクエストあたりのレスポンスが速くなる。しかし、やはり基本的にはノーマルなインスタンスサイズを選択し、スケールアウトしていく方針が良いだろう。サーバーの冗長化にも繋がる。もちろん要件にもよるが、Web サーバーは DB サーバーほど制約が多いわけではない。

Amazon EC2 の外部公開とアクセス制御

  • サーバーのインターネット公開の条件
    • EC2 をパブリックサブネットに配置する
    • EC2 にパブリック IP アドレスを付与する
    • セキュリティグループで外部からのアクセスを許可する
  • サーバーへのアクセス制御
    • セキュリティグループ
      • 仮想ファイアウォール機能
      • 設定できるルールは許可のみ
        • 特定のネットワークからの通信を拒否する設定はできない
        • 拒否設定を行いたい場合はネットワーク ACL を検討する
    • インバウンドルール
      • 外部から EC2 への通信を制御
    • アウトバウンドルール
      • EC2 から外部への通信を制御

ここではサーバーのインターネット公開の条件に「EC2 をパブリックサブネットに配置する」とあるが、通常の Web アプリケーションの構成ではプライベートサブネットに配置することになるだろう。EC2 の前段に ELB を配置することが多いからだ。外部インターネットとのやりとりは ELB が担当し、ELB さえパブリックサブネットに配置されていれば良い。ここではあくまでも、「EC2 単体で外部インターネットと接続する方法」が紹介されている。

サーバーへのアクセス制御としてセキュリティグループとネットワーク ACL (アクセスコントロールリスト) が紹介されていた。後者についてはあまり詳しくなく、どこかでキャッチアップしたい。

Amazon EC2 Auto Scaling とは

  • Auto Scaling
    • サーバーの負荷状況に応じて、自動でサーバーの追加・削除を行う機能
      • スケールアウト
        • サーバーの追加
      • スケールイン
        • サーバーの削除
  • 起動テンプレート
    • AMI と EC2 起動の設定をまとめたテンプレート
  • サーバー負荷の指標
    • CPU 使用率、ユーザーアクセス数など
  • スケーリング方法
    • ターゲット追跡スケーリング
      • 指定した値に近づくようにサーバー数を自動設定する
    • スケジューリングスケーリング
      • 曜日ごとにサーバー数を設定する
  • 予測スケーリング機能
    • サーバー数の需要を予測する
  • 利用料金
    • 無料

大事。ユーザー数の増加・アクセス数の増加に応じて、それでもサーバーダウンせずにサービスを継続できることが、クラウドの醍醐味だと考えている。柔軟なスケールアウト・スケールインが可能である。

利用料金が無料であることはありがたい。感謝して使うしかない。

AWS Lambda とは

  • Lambda
    • サーバーレスコンピューティングサービス
      • AWS により実行基盤が管理される
        • OS などのインフラ管理が不要
      • プログラムコードをアップロードして実行する
  • 実行環境
    • 標準サポート
      • Node.js、Java、Python、Ruby、Go、C#、PowerShell
    • カスタムランタイム
      • 標準サポート以外のプログラミング言語を実行する機能
    • コンテナイメージ
      • コンテナイメージを Lambda にデプロイ可能
  • 利点
    • セキュリティ
      • 実行基盤のセキュリティは AWS により管理
        • OS へのパッチ適用など
    • コスト
      • コードを実行していない時間は課金が発生しない
    • 可用性
      • AWS 管理のもと複数の AZ で実行される
        • AZ 障害時は実行可能な AZ で実行される
    • 拡張性
      • 複数の処理を受け付けると、自動的にインスタンスが拡張される
  • 欠点
    • 柔軟性
      • インスタンスタイプ、OS、ネットワーク設定などを自由に設定できない
    • コスト
      • 大量トラフィックの場合、EC2 の方が安くなる場合もある
    • 開発方式
      • Lambda には AWS 独自の開発方法や設定方法がある
      • EC2 はサーバーにプログラムをデプロイするという従来の方法で開発できる
  • 関数
    • プログラムの単位
      • 関数単位でプログラムコードを管理
      • 関数単位で処理を実行
  • 利用料金
    • リクエスト
      • リクエスト件数ごとに課金
    • 実行時間
      • インスタンスタイプ × コードの実行時間1ミリ秒ごとに課金
      • GB-秒あたりの料金設定
        • e.g. 1USD/GB-秒
          • メモリ1GBの関数が1秒間実行された
            • 1USD
          • メモリ512MBの関数が1秒間実行された
            • 0.5USD

筆者はフルスタックな Web アプリケーションに対して、Lambda を使用することにあまり慣れない。Lambda 自体を利用したことはある。しかし、開発環境で Web サーバーを立ち上げるなら、そのまま EC2 に載せてしまって良いのではとも感じる。料金が安いことも承知している。反面、リクエスト数や処理時間に対する損益分移転は意外と速いと聞く。

Lambda の用途としては、コンポーネント間を接続したり、何かをトリガーにして起動する処理が向いているという理解でいる。

AWS Lambda の実用的な使い方

  • 他サービスとの連携
    • Amazon API Gateway
      • ユーザーの HTTP リクエストをトリガーに、Lambda を実行する
        • レスポンスを返し、Web アプリケーションを構築できる
    • Amazon S3
      • S3 バケットへのデータ格納をトリガーに、Lmbda を実行する
        • 格納データを自動的に加工し、別の S3 に保存できる
    • Aamzon EventBridge
      • EventBridge のルールをトリガーに、Lambda を実行する
        • 日次実行で EC2 を起動・停止できる
  • 追加設定
    • メモリ容量
      • 関数実行時に使用できるメモリ容量を指定する
      • CPU の値は指定できない
        • メモリ容量に比例して自動設定される
    • タイムアウト時間
      • 関数が実行できる最大時間を指定する
    • 環境変数
      • 関数が利用する環境変数を指定する
  • 権限付与
    • IAM ロール
      • IAM ロールを指定し、Lambda に権限を付与する
      • IAM ロールを指定しない場合、Lambda デフォルトの IAM ロールが自動作成・付与される
        • 権限は Amazon CloudWatch へのログ送信のみ
  • モニタリング
    • Aamzon CloudWatch
      • Lambda から情報が自動送信される
        • 実行回数
        • 実行時間
        • エラー数と成功率
        • 関数のログ
    • 他のサービスと連携
      • より詳細なモニタリングをこなうことも可能

他サービスとの連携が Lambda の本領なのかもしれないと感じた。痒いところに手が届くイメージだ。

コンテナとは

  • コンテナ
    • 1つの物理サーバーで複数のコンテナが起動する
  • 仮想サーバーとコンテナの違い
    • 仮想サーバー
      • 仮想サーバーごとに実行基盤が独立している
      • 仮想サーバーごとに OS とミドルウェアが用意される
    • コンテナ
      • コンテナ間で実行基盤は共有されている
      • 各コンテナで物理サーバーの OS とミドルウェアを共有する
  • コンテナイメージ
    • コンテナの起動を定義したベースファイル
      • ファイルのパッケージ
      • OS の指定
    • コンテナイメージから複数のコンテナを起動する
      • プロセスの起動
  • レジストリ
    • コンテナイメージの管理ツール
    • レポジトリという単位でコンテナイメージを管理
  • コンテナの特徴
    • コンテナは軽量で高速
      • 軽量
        • コンテナ内に含まれるものが少ない
          • 仮想サーバーイメージ
            • OS、ミドルウェア、アプリ
          • コンテナイメージ
            • アプリ
      • 高速
        • コンテナは直接アプリを起動する
          • 仮想サーバー
            • OS を起動 → ミドルウェアを起動 → アプリを起動
          • コンテナ
            • アプリを起動
    • コンテナはデリバリーが容易
      • 起動
        • コンテナランタイムさえインストールすれば、すぐにコンテナを起動できる
      • 展開
        • レジストリにより複数環境に展開しやすい
  • コンテナオーケストレーション
    • 課題
      • さまざまなコンテナ1つ1つを運用するとコストがかかる
        • コンテナが異常終了した場合、毎回人間によるフォローを行う
        • システムの負荷が増えた場合、何台のコンテナを追加するかの判断
    • 解決
      • コンテナオーケーストレーションにより、コンテナ運用を自動化する
    • 管理
      • 状態監視
        • 異常状態になったコンテナを検知し、新規コンテナの起動を指示
      • スケーリング
        • 負荷増大を検知し、空き容量で新規コンテナの起動を指示

筆者が大好きなコンテナの話である。コンテナは OS やミドルウェアまで共有することにより、軽量化・高速化に成功したことが、大きな価値に繋がったと理解している。デリバリーが容易であることも大変ありがたく、言われてみればレジストリが整備されていることによる恩恵は大きい。

コンテナオーケーストレーションに関しては、ようするに EC2 における AutoScaling をやりたいのだと理解している。異常状態になったコンテナは自動的に再作成したいし、負荷が増大したら自動的にスケールしたいのである。Kubernetes に関してはまた別の機会に学習する。

Amazon ECS とは

  • ECS
    • マネージドなコンテナオーケストレーションサービス
      • タスク定義を元に、コンテナの状態数を維持
      • コンテナのデプロイ、状態監視、スケーリングを管理
  • ECR
    • コンテナイメージのレジストリサービス
      • コンテナイメージの管理
  • タスク
    • ECS で起動するコンテナ
  • ノード
    • コンテナを実行する1サーバー
      • 複数のコンテナを起動することもある
  • サービス
    • ALB と紐づいたタスクの集合体
  • ノードの種類
    • EC2
      • EC2 インスタンスのコンテナランタイム上でコンテナを起動する
      • EC2 インスタンスの管理をユーザー側が行う
      • ハードウェアリソースの割り当ては自由
    • AWS Fargate
      • AWS側が管理するサーバー上でコンテナを起動する
      • サーバーの管理は AWS 側が行う
      • 指定する CPU 値に対して、割り当て可能なメモリ量の範囲が決まっている
  • 利用料金
    • EC2 ノード
      • インスタンスの利用料のみ
    • AWS Fargate
      • コンテナが使用したリソース量による独自体系
        • EC2 と比較してやや割高
        • マネージドであることを考えると、懸念するほどの金額差ではない
  • Kubernetes
    • Google 製のコンテナオーケストレーションツール
  • EKS
    • AWS 上で Kubernetes を利用できるサービス

筆者が大好きな ECS の話である。コンテナでローカル開発したいし、コンテナをそのままデプロイしたいのである。一貫した実行環境でアプリケーションを開発・実行したいし、実行環境の整備をコンテナイメージにカプセル化したいのである。総じて開発・デプロイが楽だと感じている。

特に検討事項がなれば、EC2 ノードではなく AWS Fargate を選択して良い認識である。

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

  • AWS Lightsail
    • 一般的な構成の仮想サーバーを簡単に素早く構築するサービス
    • 自由にカスタムするために、簡単に EC2 へ移行する機能もある
  • AWS Elastic Beanstalk
    • 主要言語のアプリケーションのデプロイ環境を自動作成するサービス
    • デプロイ方式の他、EC2 や RDS も作成される
  • AWS App Runner
    • コンテナ化されたアプリケーションを簡単にデプロイするサービス
    • コンテナを Fargate へデプロイする
  • AWS Batch
    • プログラムを ECS や Fargate で動作させるサービス
    • 複数のプログラムの複雑な制御に特化している
      • 動作させるプログラムの順序管理や多数のプログラムの並列稼働
  • AWS Outputs
    • AWS が物理サーバーを貸し出すサービス
    • 利用者のオンプレミス環境に、AWS と同じサービスを動かすことができる
      • サーバー機器のセット
      • EC2、RDS、S3 などのサービスが動作する状態

App Runner はどこかで触りたい。バッチの実行⁨⁩は AWS Batch を利用すれば良い。

AWS Outoputs はすさまじいサービスだ。出張 AWS データセンターである。そこまでやるのか、というかそこまでパッケージングできるのかと驚いた。

Chapter4: ストレージサービス

S3 などの主要なストレージサービスを学んでいく。

Amazon S3 とは

  • S3
    • オブジェクトストレージサービス
      • ストレージ
        • データを保存する場所
      • オブジェクト
        • テキストや音声などのデータ
    • オブジェクトキーによりデータを特定して管理する
      • ファイルストレージのようなフォルダ構造は持たない
      • キーのみのため、シンプルで大容量のデータを保存・管理できる
  • 特徴
    • 容量無制限
      • 合計のオブジェクト数やデータ容量の制限はない
      • 1オブジェクトあたりは5TBまで
    • 高い耐久性
      • 標準で3つ以上の AZ にデータがコピーされる
      • 99.999999999% (イレブンナイン) の耐久性を提示
    • 低コスト
      • かなり低コストでデータ保存が可能
      • 1GB/月あたり3円
  • 他のサービスとの連携
    • Amazon VPC のフローログ
    • Amazon CloudFront のアクセスログ
    • EBS のスナップショット保存
  • 利用料金
    • データ保存容量
    • データアクセス回数
    • データ転送量

AWS のあらゆるデータ保存に使用されている S3 の紹介だ。その特徴は高い耐久性と低コスト。S3 の裏側ではデータは自動的に3つの AZ にコピーされることは知らなかった。思ったよりデータセンターのストレージ容量がかかりそうだ。反面、低コストであり 1TB で3,000円/月だ。1TB で3,000/円か...意外と激安ではないのかも。それでも、動画や音声ファイルの大規模データを溜め込んだり、ビッグデータのような極端に大量のデータを溜め込まない限りは、システム全体の費用を支配的に圧迫することはないのではないか。

Amazon S3 の基本

  • バケット
    • オブジェクトを保存する場所
    • 名前は全世界の全リージョンで一意である必要がある
  • オブジェクト
    • バケットに格納されるデータ本体
  • キー
    • オブジェクトの格納 URL パス
  • 3者の関係性
    • 「バッケット名 + キー名 + オブジェクト名」で一意になる
      • S3 は実態としてフォルダを持たない
      • 「/」を区切り文字として、マネジメントコンソール上ではフォルダ構造で表示される

ようするに KVS (Key-Value ストア) と同じ仕組みだ。バケット名にユニークキー制約がかけられており、全世界で重複したキーが作成されることはない。「/」によるフォルダ表示は、それでも認知負荷削減のために階層管理したい人間による都合で、AWS の温情である。

ここで「マネジメントコンソール上で階層表示するための処理が複雑にならないか？」という疑問が湧く。S3 オブジェクトはキー・バリュー形式で保存されているはずだ。それが特徴なのだから。ではある階層の S3 オブジェクトの一覧を表示したいとき、すべての S3 オブジェクトのキー名を取得する必要がある。RDS だったら階層 ID なりを指定して、階層内のオブジェクトのみを検索できる。S3 のキー・バリュー形式では余計な検索コストがかかってしまうのではないか。

おそらく、というか確実に問題にならないはずだ。上記の発想は、我々プログラマーがプログラム経由の S3 アクセスより、S3 のマネジメントコンソールを見る機会の方が多いから出てくるものだ。S3 への大多数のアクセスはプログラム経由であり、その高速化のためのキー・バリュー形式なのだ。

Amazon S3 のライフサイクルとバックアップ

  • ストレージクラス
    • コストや可用性の異なる複数のグレードが用意されている
      • 標準 (STANDARD)
      • Intelligent-Tiering
      • 1ゾーン低頻度アクセス
      • ...
      • S3 Glacier Deep Archive
  • ストレージクラスの選択
    • 標準
      • Web ページのコンテンツなど、いつでも利用できるようにするデータ
    • S3 Glacier Deep Archive
      • データは念のため保存するが、使用することはほとんどないケース
  • ライフサイクル設定
    • 自動的にストレージクラスを変更できる機能
      • 時間経過で低コストのストレージクラスへの移行や、オブジェクトの削除ができる
      • 一度でも低コストのストレージクラスへ移行した後、標準クラスへ戻すことはできない
  • S3 Analytics
    • オブジェクトへのアクセス状況を確認する機能
    • 適切なストレージクラスの選択の助けになる
  • バージョン管理
    • オブジェクトの履歴を管理する機能
    • オブジェクトを削除しても、復旧することができる
      • DELETE 操作はオブジェクトの論理削除となる
      • 特定操作でオブジェクトを完全に削除することもできる
    • 過去バージョンも1オブジェクトとして課金される
      • ライフサイクル設定により、過去バージョンを削除することもできる
  • クロスリージョンレプリケーション (CRR)
    • 海外リージョンにデータをコピーする機能

ライフサイクルで自動的にストレージクラスを変更できる機能はありがたい。特にログデータなどは一生溜まっていくかつ大容量になりがちであり、特定に応じてうまくコスト最適化できれば嬉しい。

バージョン管理機能は、特性によるがコンテンツに対しては基本的に ON にして良いだろう。謝って秘密情報をアップロードしてしまった場合、通常の削除操作ではなく、オブジェクトを完全に削除する操作を行う必要がある。

Amazon S3 の外部公開とアクセス制御

  • アクセス制御の種類
    • IAM ポリシー
      • データを操作するユーザー側を制御する
    • ACL
      • バケット単位、オブジェクト単位で細かくアクセス制御できる
        • バケットポリシーよりも細かく制御できる
    • バケットポリシー
      • バケット単位で JSON でアクセス制御できる
  • ブロックパブリックアクセス
    • 意図せず S3 オブジェクトが公開状態になることを防ぐ機能
  • Web サイトホスティング機能
    • オブジェクトを Web コンテンツとして公開する機能
    • ACL やバケットポリシーを活用し、特定ユーザーのみにコンテンツ公開することもできる
    • S3 のみでは HTTP アクセスとなる
      • CloudFront を利用すると HTTPS アクセスできる
  • 保存データの暗号化
    • バケットでデフォルトの暗号化を有効にできる
      • オブジェクト格納時に自動的に暗号化する
    • キーには AWS KMS など3種類から選択できる

Amazon EBS とバックアップ

  • EBS
    • EC2 のストレージサービス
  • 性能値
    • 書き込み・読み込みの1秒あたりの回数
      • IOPS (Input/Output Per Second)
  • ボリュームタイプ
    • 書き込み・読み込み速度に応じた種類
      • 汎用 SSD
        • 特別な性能要件がない場合
      • プロビジョンド IOPS SSD
        • 高性能なアプリケーションが求められる場合
      • スループット最適化 HDD / Cold HDD
        • できるだけ安価にしたい場合
  • スナップショット
    • EBS データのバックアップ機能
    • 決まったサイクルでバックアップを取得し、S3 に保存する
      • この S3 は利用者には見えない
      • 2回目以降のスナップショットは差分データであり、コストが安い
  • 利用料金
    • データ保存容量
    • IOPS (読み書き回数)
      • データ保存容量と比較して安価
    • データ処理容量
      • データ保存容量と比較して安価

基本的にボリュームタイプの選択は汎用 SSD でよい理解でいる。

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

  • Amazon Elastic File System
    • 複数の EC2 インスタンスから同時利用可能な比較的高速なストレージ
      • EBS
        • 1つの EC2 にアタッチする非常に高速なストレージ
      • S3
        • 多くのクライアントから同時利用可能な遅いストレージ
          • HTTPS を利用した API アクセス
    • NFS (Network File System) プロトコルを利用
      • 比較的高速にデータを転送できるプロトコル
      • Linux のみ対応、Windows Server は非対応
  • Amazon FSx
    • ファイルサーバーを構築するためのサービス
      • SMB (Server Manage Block)
        • 主に Windows で利用されるファイル共有プロトコル
      • Lustre
        • 大規模なクラスターコンピューティングで使用される高性能なファイルシステム
  • AWS Storage Gateway
    • データをオンプレミス機器から AWS 上のサービスへやり取りするサービス
  • AWS Transfer Family
    • FTP 系のプロところ流で通信するサーバーを構築するサービス
  • AWS Backup
    • AWS のストレージやデータベースサービスのデータをバックアップするサービス
  • AWS DataSync
    • オンプレミスと AWS、もしくは AWS ストレージサービス間でデータの転送を行うサービス
  • AWS Snow Family
    • テラバイトクラスの大規模データ転送をできるだけ高速に行うサービス
      • 100TB を 1Gbps のインターネット回線で転送すると、約10日かかる
    • 物理的なストレージを AWS から借り、データを格納して AWS に返送する

Chapter5 ネットワークとコンテンツ配信サービス

ネットワークおよびコンテンツ配信のサービスを学んでいく。

ネットワークの基礎知識

IP アドレス

  • IP アドレス
    • ネットワーク上のサーバーの住所
  • IPv4
    • 4つの数値からなる IP アドレス
      • 192.168.1.1
        • 1つの数値の範囲は0〜255
        • 2^32個 = 43億個のパターンが存在
  • パブリック IP アドレス
    • 世界中で識別可能な IP アドレス
  • プライベート IP アドレス
    • LAN 内のみで識別可能な IP アドレス
      • ローカルエリアネットワーク
    • 利用可能な IP アドレスの範囲
      • 10.0.0.0 - 10.255.255.255
      • 172.16.0.0 - 172.31.255.255
      • 192.168.0.0 - 192.168.255.255
  • CIDR ブロック
    • IP アドレスの範囲の表記方法
      • 172.31.0.0/16
        • ネットワーク部
          • ネットワークを表す
        • ホスト部
          • ネットワーク内の⁩ホストを表す
            • 接続可能なサーバーなど
        • サブネットマスク
          • IP アドレスのネットワーク部の範囲を表す
          • 10進数 N で表記し、IP アドレスの上位 N ビットがネットワーク部となる
    • サブネットマスクの指定と利用可能個数
      • 10.0.0.0/16
        • ネットワーク部
          • 10.0
            • 00001010 00000000
        • ホスト部
          • 0.0
            • 00000000 00000000
            • 2^16 = 65,536個
      • 10.0.0.0/28
        • ネットワーク部
          • 10.0.0
            • 00001010 00000000 00000000 0000
        • ホスト部
          • 0.0
            • 0000
            • 2^4 = 16個

CIDR は Classless Inter-Domain Routing（クラスレスドメイン間ルーティング）の略称だ。従来の「クラス A/B/C」による固定的な分割をやめて、柔軟にネットワークを区切る方法として導入された。AWS では VPC やサブネットの作成時に使用する。 by LLM

毎回感じるが、CIDR ブロックの表記と値がややこしい。そもそもとして、IP アドレスの実態は「32ビットの2進数」なのだ。たとえば 00001010000000000000000000000000 である。人間には読みづらく、これを8桁ごとに区切って10進数に変換したものが 10.0.0.0 である。

CIDR ブロックは IP アドレスの範囲を表現する表記法だ。末尾のサブネットマスクの数値により、上位 N ビットがネットワーク部であり、残りのビット数が IP アドレスの範囲となる。2^(32 - N) の個数が使用できるようになる。具体的な個数の例は次のとおりだ。

  • /16: 2^16 = 65,536 個
  • /24: 2^8 = 256 個
  • /28: 2^4 = 16 個

VPC とサブネットの CIDR ブロックのサブネットマスクは、/16 ～ /28 の範囲で指定する。さらに以下の5個の IP アドレスは AWS により予約され、使用できない。[1]

  • 最初の1つ目 (e.g. 10.0.0.0): ネットワークアドレス
  • 2つ目 (e.g. 10.0.0.1): VPC ルーター用
  • 3つ目 (e.g. 10.0.0.2): Amazon DNS サーバー
  • 4つ目 (e.g. 10.0.0.3): 将来利用
  • 最後 (e.g. 10.0.0.255): ネットワークブロードキャストアドレス

ではいったい、サブネットマスクの数値は /16 ~ /28 のどれにしたら良いのだろう？

まずは、CIDR ブロックの上限個数を確認してみよう。プライベートサブネットに割り当て可能な IP アドレスの範囲は、次のとおりだった。末尾に個数を追記している。

  • 10.0.0.0 - 10.255.255.255 (2^24 = 16,777,216 個)
  • 172.16.0.0 - 172.31.255.255 (2^20 = 1,048,576 個)
  • 192.168.0.0 - 192.168.255.255 (2^16 = 65,536 個)

サブネットマスクに最大の /16 を指定した場合、2^16 = 65,536 個の IP アドレスの範囲を確保する。CIDR ブロックを指定できる個数は、10.0.0.0 - 10.255.255.255 であれば256個、172.16.0.0 - 172.31.255.255 であれば16個、192.168.0.0 - 192.168.255.255 であれば1個となる。合計で274個だ。※計算方法は愚直に行っても良いが、末尾16桁の範囲を何個確保できるか、をイメージすると理解しやすい

計274個の割り当てを VPC で使い切るかどうかは...どうだろう？通常は274個の VPC を設定することはないだろう。Web アプリケーションではまず使い切ることはないと考えている。

次に、現実的に必要な IP アドレスの個数を確認してみよう。サブネットマスクに最小の /28 を指定した場合、2^4 = 16 個の IP アドレスの範囲を確保する。たった16個だ、足りるだろうか？

そもそも VPC やサブネットで確保した IP アドレスは何に使用されるのか。前述のとおり、5個は AWS 側で予約されるため使用できない。残りをサブネット内の AWS リソースに割り当てることになる。具体的には次のとおりだ。

  • EC2 インスタンス
  • RDS / ElastiCache / Redshift
  • ALB / NLB
  • ECS / EKS のタスクや Pod

正直、調べてもよくわからない。ALB の作成には最低8個の IP アドレスが必要なようだ。[2] EC2 や EKS では起動するタスクや Pod の数だけ必要になりそうだ。/28 (16個) は少ないにしても、/24 (256個) はどうだろう？大規模サービスなら使い切ってしまうこともありそうで少し怖い、安心して夜を眠れるかと問われれば微妙なラインだ...。

結論を書こう。一般的にサブネットマスクの数値は、VPC には /16 程度の大きめのものを、サブネットにも /24 程度の大きめのものを指定することが多いようだ。[3] 前にどこかで参考値を見かけた気がするが忘れてしまった。詳しい方がいましたら教えてください。

長くなってしまったが、IP アドレスと CIDR ブロックの探求の旅を終わりにして、次に進もう。

セキュリティ

  • ファイアウォール
    • 不正なアクセスを遮断する機能

お世話になっております。

負荷分散

  • ロードバランサー
    • トラフィックの負荷分散装置

「ロードバランサー is 何」と感じていた時期が私にもありました。サーバーあたりのトラフィックの分散する装置だ。分散方式には複数あるが、とりあえずスタンダードには均等してトラフィックを分散していると考えれば良い。4台のサーバーを用意したとする。100万件のリクエストがあれば、ロードバランサーはサーバー1台あたり25万件のリクエストが割り振られるように、トラフィックの送信先を調整する。

ルーティング

  • ルーター
    • 異なるネットワークを繋ぐ中継機
  • ルーティング
    • ルーターが目的の IP アドレスへの道順を決めること
      • インターネットは複数のネットワークの集合体
        • どのようになルーター経由が効率的か経路選択が必要になる
        • インターネット経由のアクセスは、複数のルーターを経由する
  • ルーティングテーブル
    • ルーターが所有する経路情報
      • AWS VPC のルートテーブル

正直、よく理解できていない。理解の優先度を下げて良いと考えている。

名前解決

  • ドメイン
    • ドメイン名とサイトの所在を定義
      • example.com
  • DNS
    • ドメイン名を IP アドレスの紐付けを解決するシステム

新しいサービスを立ち上げるとき、ドメインを購入して DNS に登録するやつだ。

Amazon VPC とは

  • VPC
    • プライベート仮想ネットワーク空間
      • Virtual Private Cloud
    • パブリックな VPC やプライベートな VPC を作成できる
  • CIDR ブロック
    • 通常はプライベート IP アドレスを指定する
      • パブリック IP を指定することも可能だが...
        • 外部のパブリック IP と重複すると、通信できなくなる
    • 接続するネットワークと VPC の CIDR ブロックが被らないようにする
      • 他の VPC
      • 外部ネットワーク
    • ホスト部は余裕を持って確保する
      • 最初から最終的に必要になる IP アドレスの総数を把握することは困難
      • AWS が自動的に使用する IP アドレスもある
  • サブネットマスク
    • /16 以下を推奨
  • VPC の作成
    • VPC 名
    • CIDR ブロック
    • IPv6 の設定
    • テナンシー
      • 専用ハードウェアを使用するか
  • サブネット
    • VPC のネットワークの分割単位
      • 特徴
        • VPC の範囲内で CIDR ブロックを指定する
        • 1つのサブネットは1つの AZ に所属させる必要がある

IP アドレス のセクションでだいぶ深掘りしてしまい、こちらで書くことは特にない。

Amazon VPC の主要機能

インターネット接続

  • ルートテーブル
    • ネットワークの経路情報
    • サブネットごとにルートテーブルを割り当てる
  • インターネットゲートウェイ
    • サブネット内のサーバーをインターネットと通信できるようにする機能
      • VPC からインターネットへの通信が可能
      • インターネットから VPC への通信が可能
    • ルートテーブルにインターネットゲートウェイを設定する
  • NAT ゲートウェイ
    • VPC からインターネットへ一方通行に接続する機能
      • インターネットから VPC へは接続できない
      • EC2 でパッケージのインストールなどに使用できる
    • ルートテーブルに NAT ゲートウェイを設定する
  • パブリックサブネット
    • インターネットゲートウェイのルートが設定されたサブネット
  • プライベートサブネット
    • インターネットゲートウェイのルートが設定されていないサブネット
  • EC2 の IP アドレス
    • パブリック IP
      • 自動設定される IP アドレス
      • EC2 再起動のたびに変更される
    • Elastic IP
      • 利用者が確保する静的 IP アドレス
      • EC2 再起動しても変わらない

インターネットゲートウェイと NAT ゲートウェイの対比、およびパブリックサブネットとプライベートサブネットの定義がわかりやすかった。

特に NAT ゲートウェイが肝である。EC2 をパブリックサブネットに所属させつつ、NAT ゲートウェイを通して EC2 から外部インターネットへ通信が可能である。外部インターネットから EC2 への通信ができない。これでセキュリティも確保しつつ、パッケージソフトウェアのインストールなどが可能になる。

アクセス制御

  • ネットワーク ACL
    • サブネット単位でアクセス制御する機能
  • 2つのアクセス制御
    • ネットワーク ACL
      • サブネット単位で設定
      • ルールの許可と拒否が可能
      • ステートレス（行き戻り両方の許可が必要）
      • ルールの優先順位を指定
    • セキュリティグループの活用
      • インスタンス単位で設定
      • ルールの許可のみ可能
      • ステートフル（行きのみの許可でOK）
      • すべてのルールを評価

ログ

  • VPC フローログ
    • VPC 内の IP トラフィック状況のログ
      • 許可された通信
      • 拒否された通信
    • 保存先は CloudWatch Logs か S3

Amazon VPC の外部接続

VPC と外部ネットワーク

  • VPC ピアリング
    • 2つの VPC を接続して通信できるようにする機能
  • AWS Transit Gateway
    • VPC の接続を中央ハブ1箇所で管理できる機能
    • VPN などのオンプレミス環境との接続にも使用できる

VPC ピアリングの利用イメージがつかめていない。VPC 同士で通信したいなら、VPC 同士で通信を許可するセキュリティルールの設定をすればよいのでは？と感じた。おそらく他のネットワークの VPC と通信するサービスなんだろうな、という温度感でいる。

VPC と外部 AWS サービス

  • VPC エンドポイント
    • VPC 外部の AWS サービスへプライベートネットワーク経由で接続する機能
  • ゲートウェイエンドポイント
    • パブリック IP アドレスを指定するが、AWS 内の通信になる VPC エンドポイント
    • S3 と DynamoDB で使用する
  • インターフェースエンドポイント
    • プライベート IP アドレスを指定し、AWS 内で通信する VPC エンドポイント
      • AWS PrivateLink を使用する
      • サブネットにサービス接続用のネットワークインターフェース (ENI) を作成する
    • 多くの AWS サービスが対応している

VPC とオンプレミス

  • AWS Site-to-Site VPN
    • オンプレミス環境のネットワークと VPC 間で VPN 接続を行う機能
  • Client VPN
    • オンプレミス環境全体ではなく、特定の端末とプライベートに通信する機能
  • AWS Direct Connect
    • オンプレミス環境と AWS を専用線で接続する機能

Amazon VPC の構成例

書籍では主に図で紹介されており、ぜひ参照されたい。

AWS サービスの分類

  • 稼働場所による分類
    • グローバルサービス
      • 特定のリージョンに依存せず稼働するサービス
        • CloudFront、IAM など
    • リージョンサービス
      • 特定のリージョン内で稼働するサービス
        • S3、DynamoDB など
    • AZ サービス
      • 特定の VPC 内で稼働するサービス
        • EC2、RDS など

DynamoDB がデータベースでありながらリージョンサービスということに驚いた。AZ をまたがって存在しているらしい。S3 のように異なる AZ にデータを分散しているのだろうか？

Web + DB + CloudFront

  • VPC 外
    • CloudFront を配置する
    • コンテンツをキャッシュする
  • パブリックサブネット
    • ALB を配置する
    • VPC 外部から通信を受け取る
  • プライベートサブネット
    • EC2 や RDS のリソースを配置する
  • サブネットの分割
    • サーバーの役割ごとにサブネットを作成する
    • サーバーの役割ごとに複数のサブネットを用意する

もっとも一般的な構成だろう。パブリックサブネットに ALB を配置して、外部インターネットとの中契約を担う。後続の AWS リソースはプライベートサブネットに所属させ、セキュリティグループでアクセス制御を行う。AWS リソースおよびサブネットはマルチ AZ 配置し、冗長化する。

「Amazon VPC の構成例」セクションではあと2つ紹介されていたが、割愛する。

  • VPC エンドポイントを使用した S3 接続
  • オンプレミス環境からプライベート接続

Elastic Load Balancer とは

ELB の機能

  • ELB
    • AWS のロードバランサーサービス
      • アプリケーションへのトラフィックの負荷分散を行う
      • トラフィック先のサーバーの死活監視を行う
  • 負荷分散
    • 大量のトラフィックを複数台のターゲットに分散する
    • 各ターゲットを異なる AZ に配置し、地理的な可用性を高める
    • ELB 自体は負荷状況により自動スケールする
      • 利用者は ELB の性能低下を気にする必要はない
  • ターゲットモニタリング
    • ターゲットに対する接続を常に監視する
    • リクエスト追跡や CloudWatch メトリクスの取得を可能とする
  • セキュリティ機能
    • セキュリティグループなどを適用できる
    • SSL/TLS サーバー証明書による通信の暗号化ができる

ELB 自体は負荷状況により自動スケールする

知らなかった。やはりすべてが冗長化されている。

ELB の種類と利用料金

  • ELB の種類
    • 4種類のロードバランサー
      • ALB (Application Load Balancer)
        • HTTP/HTTPS トラフィックの負荷分散を行う
        • レイヤー7 (アプリケーション層) で動作する
        • マイクロサービスやコンテナなどのさまざまなアプリケーションに対応できる
      • NLB (Network Load Balancer)
        • HTTP/HTTPS、TCP、UDP、TLS トラフィックの負荷分散を行う
        • レイヤー4 (トランスポート層) で動作する
        • 数百万の大規模トラフィックでも高速なパフォーマンスを提供する
      • CLB (Classic Load Balancer)
        • 旧タイプのロードバランサー
        • レイヤー4 (トランスポート層) とレイヤー7 (アプリケーション層) で動作する
        • 基本的には使用しない
      • GWLB (Gateway Load Balancer)
        • AWS 上で提供されるサードパーティ製品のデプロイ・管理を行う
        • レイヤー3 (ネットワーク層) で動作する
        • 従来のアーキテクチャをシンプルに実装可能
          • LNB、VPC ピアリング、Transit Gateway
    • 選定
      • ALB
        • Web アプリケーションの負荷分散
      • NLB
        • ALB では実現できない細かい制御
        • HTTP/HTTPS 以外のプロトコルの使用
  • 利用料金
    • 台数 × 利用時間
    • ロードバランサーキャパシティユニット (LCU)
      • 台数 × 利用時間よりも比較的安価
      • 料金要素の中から最も高いもので決定

ロードバランサーの種類が多く、特徴を掴み損ねていたが、とりあえず ALB と NLB を念頭に置けば良いと再整理できた。

Amazon Route 53 とは

Route 53 の基本

  • Route 53
    • フルマネージドな DNS サービス
  • ホストゾーン
    • ドメインとサブドメインのトラフィックルーティング方法の設定
  • 特徴
    • 高い可用性
      • SLA は 100%
      • Route 53 の基盤システムは全世界に冗長化されている
    • 高いコストパフォーマンス
      • ドメイン登録は 0.5USD/個
        • 最初の25個までは
  • ドメイン登録
    • ドメイン登録機能
      • ドメイン名を DNS レコードとして登録する機能
    • DNS レコード
      • ドメインと IP アドレスなどの情報を紐付けるデータ
    • DNS レコードタイプ
      • 一般的な DNS レコードタイプ
        • A レコード
          • IPv4 の IP アドレスを指す
            • Web サイトや Web サーバーなど
        • AAAA レコード
          • IPv6 の IP アドレスを指す
            • Web サイトや Web サーバーなど
        • CNAMEレコード
          • ドメインのエイリアスを指定する
            • www.example.com/blog. IN CNAME blog.example.com.
        • NS レコード
          • ドメインのネームサーバーを指定する
            • example.com NS ns1.example.com

SLA 100% の狂気。ビジネスにおける 100% がこんなところに存在していたとは。

Route 53 の機能

  • トラフィックルーティング
    • ルーティングポリシー
      • DNS レコードごとのルーティングの設定
      • ドメインに対して IP アドレスを返却する方法
    • ルーティングポリシーの種類
      • シンプルルーティング
        • 1つのドメインに対し1つの IP アドレスが紐づく
      • 荷重ルーティング
        • 複数の IP アドレスを登録する
        • トラフィックをどの程度振り分けるかの荷重を指定する
      • 位置情報ルーティング
        • 複数の IP アドレスを登録する
        • 問い合わせ元の位置情報により、どの IP アドレスを返すか決める
      • レイテンシールーティング
        • 複数の IP アドレスを登録する
        • 常にレイテンシーが最小となるリソースの IP アドレスを返す
      • フェイルオーバールーティング
        • プライマリとセカンダリの IP アドレスを登録する
        • 通常はプライマリへルーティングし、障害時にはセカンダリへルーティングする
      • 複数値回答ルーティング
        • 複数の IP アドレスを登録する
        • 問い合わせに対し、常にランダムに IP アドレスを返す
  • リソースのヘルスチェック
    • 正常性判断の基準
      • サーバーからの応答結果
      • 他サービスのヘルスチェック
      • CloudWatch アラーム
    • 利用料金
      • ヘルスチェックの料金は意外と高く、要件をよく確認しよう

ELB と同様、Route 53 にもルーティングとヘルスチェックの機能が備わっている。EC2 の Auto Scaling も含め、この3つは役割が似ていると感じている。

Amazon CloudFront とは

CloudFront の基本

  • CloudFront
    • コンテンツデリバリーネットワーク (CDN) サービス
  • CDN
    • 概要
      • 大容量デジタルコンテンツを効率的にユーザーに配信するネットワーク
        • 動画ファイルなど
    • オリジンサーバー
      • データ本体を格納しているサーバー
    • キャッシュサーバー
      • 世界中に存在するキャッシュ専用のサーバー
    • ユーザーアクセス
      • 自動的に自分に一番近いキャッシュサーバーにアクセスする
  • エッジロケーション
    • 世界中にあるグローバルサービスのサーバーの拠点
      • リージョンや AZ とは別のデータセンターとして設置
    • 47カ国90都市以上、275箇所が存在する
  • メリット
    • 高速配信
      • 大容量コンテンツを効率的にユーザーへ配信できる
    • セキュリティ向上
      • 自動的に通信の SSL/TLS 暗号化を行う
      • CloudFront には自動生成されたドメイン名が割り当てられる
        • ドメイン名に対応した証明書が自動的に割り当てられる
        • そうなんだ
    • 可用性向上
      • 全世界にエッジロケーションを持っている
      • オリジンサーバーへの負荷が軽減される

エージロケーションに対して懐疑的である。王道的な説明として「地理的な距離が縮まり、レスポンスが速くなる」がある。しかし、たかが知れてはいないだろうか？全国47カ国の地点分散でどこまでの領域をカバーし、いったいどの程度速くなるのだろう？今まで大陸のサーバーへ接続していたユーザーが隣国のサーバーへ接続できるようになったとして、果たしてその地理的な距離の短縮が、どれだけ通信の高速化に影響するするのだろうか。通信を高速化したいと考えるとき、どうしても地理的な要因よりも、帯域幅などの他の要因の方が支配的に思えてしまう。

ということで、コンピュータやネットワークの処理にどの程度の時間がかかるのか見てみよう。[4]

操作内容 所要時間（ns = ナノ秒）
L1 キャッシュ参照 0.5ns
分岐予測ミス 5ns
L2 キャッシュ参照 7ns
ミューテックス ロック／アンロック 100ns
メインメモリ参照 100ns
1KBの zip 圧縮 10,000ns (10μs)
2KBを1Gbpsネットワークで送信 20,000ns (20μs)
メモリから1MBを連続読み込み 250,000ns (250μs)
同一データセンター内の往復 500,000ns (500μs)
ディスクのシーク 10,000,000ns (10ms)
ネットワークから1MBを連続読み込み 10,000,000ns (10ms)
ディスクから1MBを連続読み込み 30,000,000ns (30ms)
カリフォルニア → オランダ → カリフォルニア間パケット送信 150,000,000ns (150ms)

※ 1 = 1,000m (ミリ)、1m = 1,000μ (マイクロ)、1μ = 1,000n (ナノ)

諸説あるが、一例としてサーバーのレスポンスタイムは 300ms 以下が推奨されている。[5] サーバーの応答時間とそれぞれの処理にかかる時間を比べてみよう。

この表からわかることがまとめられている。

  • データセンター間の通信は非常に時間がかかる
    • カリフォルニアはアメリカに位置し、オランダはヨーロッパに位置している
    • 両者の間には太西洋があり、直線距離で約9,000km離れている (往復は約1.8万km)
    • ざっくりと、大陸を跨ぐ通信には往復で 150ms かかる
  • メモリは高速だが、ディスクは低速である
    • 1MB のデータを読み込む場合、メモリは 250μs でディスクは 30ms だ
    • ディスク読み込みよりはメモリ読み込みの120倍コストがかかる
  • 書き込みは読み取りよりも 40 倍コストがかかる
  • チープな圧縮アルゴリズムを使用することで、ネットワーク帯域幅を大幅に（2分の1程度）節約できる

また、大陸間通信にかなりの時間がかかることがわった。サーバーのレスポンスタイムを 300ms 以下に収めたい時、大陸間通信だけで半分を消費してしまう。たしかにエッジロケーションおよび CDN は有効だ。

CloudFront の設定と利用料金

  • 設定
    • ディストリビューション
      • オリジンサーバーに配置したファイルの情報
      • 1つのディストリビューションに対し1つの CloudFront ドメインが割り当てられる
    • AWS WAF
      • CloudFront の前段として設置する
      • Web アプリケーションファイアウォールを設定できる
        • IP 制限や脆弱性対応が可能
      • 追加料金がかかる
    • オリジン設定
      • コンテンツの元データのオリジンリソースを設定する
      • ドメイン単位で設定する
        • S3 や ELB など
        • 自己管理しているドメイン
    • その他
      • 詳細設定
        • ビヘイビア
          • プロトコルの設定
          • HTTP メソッドの設定
          • キャッシュの設定
            • 特に重要
        • エラーページ
          • オリジンでの障害発生時の動作
        • 地理的制限
          • 特定の国ごとにアクセス許可・拒否を設定
        • キャッシュ削除
          • CloudFront 上のキャッシュを手動で削除する
  • 利用料金
    • データ転送量
    • リクエスト数

その他のネットワークとコンテンツ配信サービス

  • オンプレミスと AWS の接続
    • 主に4つの方法
      • サイト間 VPN
        • VPN 機器を利用する
        • VPN 配下のすべてのサーバーが VPC と通信できる
      • VPN
        • インターネットを仮想的に専用線のように扱う技術
        • 通信の機器間で、通信の暗号化と経路の制御を行う
      • 専用線
        • 拠点間に物理的に敷設された専用の通信回線
        • 回線所有者の独占利用となるが、導入費用は高額
      • リモートアクセス VPN
        • VPN 接続ソフトを利用する
        • VPN 接続しているサーバーのみが VPC と通信する
  • AWS Direct Connect
    • AWS とオンプレミス環境の間に専用線を引くサービス
  • AWS VPN
    • AWS からオンプレミス環境に VPN を構築するサービス
      • AWS Site-to-Site VPN
        • サイト間 VPN を構築するサービス
      • AWS Client VPN
        • リモトーアクセス VPN を利用できるようにするサービス
  • AWS Trasit Gateway
    • VPC 接続をまとめるためのサービス
  • AWS PrivateLink
    • VPC エンドポイントを作成するサービス
    • VPC ピアリングと異なり、接続先を制限できる
  • Amazon API Gateway
    • Web API を作成するサービス
    • Web サーバーが要らず、処理サーバーのみ構築すれば良くなる
    • API 作成に関する機能が豊富
      • 認証機能
      • エラー率や処理時間の監視
  • AWS Global Accelerator
    • クライアントがより高速に AWS システムへ到達できるようにするサービス
      • 国境を越える通信の高速化
  • AWS Ground Station
    • 人工衛星の利用予約と基地局との通信ができるサービス
    • 利用には米国のアマチュア無線ライセンス (FCC) が必要

Chapter6 データベースサービス

データベースのサービスを見ていこう。多種多様な方式に対応したサービスが用意されている。

データベースとは

  • データベース
    • 整理されたデータの集まり
    • データの検索や登録が容易にできる
  • データベース管理システム
    • データの更新・参照・削除などの操作を受けて、データを管理するシステム
  • リレーショナルデータベース
    • 表形式のデータベース
  • NoSQL データベース
    • キー・バリュー型のデータベース
  • SQL
    • データ操作のための言語
  • ACID 特性
    • トランザクションの信頼性と整合性を保証する4つの特性
      • 原子性 (Atomicity)
        • トランザクションは完全に実行されるか、全く実行されないかのいずれかである
      • 一貫性 (Consistency)
        • トランザクションが成功すると、データベースの整合性制約をすべて満たす
      • 独立性 (Isolation)
        • トランザクションを単独実行しても、同時に複数実行しても、同じ結果となる
      • 持続性 (Durability)
        • システム障害が発生しても、完了したトランザクションの結果は失われない

書籍ではかなり基礎的な知識から紹介されていた。

Amazon RDS とは

RDS

  • RDS
    • OS やデータベースエンジンの管理は AWS 側で行う
    • リレーショナルデータベースを提供するサービス
  • データベースエンジン
    • MySQL、PostgreSQL、SQL Server、Oracle、MariaDB、Amazon Aurora
  • RDS の作成
    • デーベースエンジン、バージョン
    • DB インスタンス識別子
      • 名前
    • マスターユーザー名、パスワード
      • ログイン時に使用
    • DB インスタンスクラス
      • マシン性能
    • ストレージタイプ設定
      • ストレージ容量や性能
    • マルチ AZ 配置
    • ネットワーク設定
      • 配置する VPC など
  • インスタンス
    • RDS で稼働するサーバー
  • インスタンスタイプ
    • db.m6g.large
      • 名前のルール
        • db は固定
        • ファミリー (m)
          • インスタンスの特徴
        • 世代 (6)
          • 数が大きいほど新しく高性能
        • 追加機能 (g)
          • g
            • Gravition2 (CPU の名前)
        • サイズ (large)
          • サイズが大きいほど高性能
  • ストレージタイプ
    • 汎用 SSD
      • 高性能で、データ容量により読み書き性能が決定
    • プリビジョンド IOPS SSD
      • 高性能かつ、指定された読み書き性能を維持
    • マグネティック HDD
      • 低コスト
  • 利用料金
    • 利用時間

インスタンスタイプは先頭に db が付与される以外は、EC2 と同じだ。ストレージタイプはまずは汎用 SSD を選択し、要件や実際の性能を見ながら調整すれば良いだろう。

高可用性の実現

  • マルチ AZ 配置
    • RDS インスタンスを複数の AZ に配置する構成
  • プライマリインスタンス
    • メインでデータ処理を行うインスタンス
  • スタンバイレプリカ
    • 障害発生時に切り替え先となるインスタンス
    • 通常はデータ処理を行わない
  • リードレプリカ
    • プライマリインスタンスから複製された読み込み専用のインスタンス
    • スケールアウト方式でパフォーマンス向上を図る
  • フェイルオーバー
    • 障害発生時に正常なインスタンスに接続先を切り替えること
  • エンドポイント
    • DNS 形式の RDS の接続情報

基本的にプライマリインスタンスを1台、スタインバイレプリカを1台、リードレプリカを複数台、稼働している認識だ。やはり DB の冗長化させたい、そしてほとんどの Web アプリケーションは書き込みが少なく、読み込みが圧倒的に多い。書き込みを行うプライマリインスタンスは1台で対応し、変更をリードレプリカへ反映する。リードレプリカを複数台稼働させることにより負荷分散を図る。

スタンアバイレプリカを常時1台稼働させており、そのインスタンスは通常時は遊んでいることに驚いた。書き込み・読み込み両方を兼任できるインスタンスは Aurora で実現されており、RDS では物理的なインスタンスを増やして冗長化を行なっているようだ。

セキュリティとメンテナンス

  • アクセス制御
    • VPC
      • VPC 内に作成
    • サブネット
      • 異なる2つ以上のサブネットが必要
    • アクセス制御
      • セキュリティグループとネットワーク ACL で設定
  • データベースエンジンのアップデート
    • 更新作業
      • AWS 側で実施される
    • メンテナンスウィンドウ
      • 利用者が設定する更新作業を行う時間帯
    • オフライン
      • いくつかのメンテナンス作業では、RDB インスタンスが一時的にオフラインになる
    • 更新順序
      • マルチ AZ 配置の場合
        • メンテナンスは、スタインバイレプリカ → プライマリレプリカの順番で実施される
        • ただし、新しいバージョンへのアップデートは、両方のレプリカが同時にアップデートされる

アクセス制御に関しては EC2 と同じだ。

データベースエンジンのアップデートは、まずはメンテナンスウィンドウに気をつければ良い。またマルチ AZ 配置の場合、バージョンアップはスタンバイレプリカとプライパリレプリカの両方が同時にアップデートされるらしい。バージョンアップ作業によりどのくらいダウンタイムが発生するかが気になるが、後で調べよう。

Amazon Aurora とは

  • Aurora
    • AWS に最適化されたデータベース
    • MySQL と PostgreSQL に互換性あり
  • 全体構造
    • DB クラスター
      • Aurora の1管理単位
        • クラスター内のインスタンスでストレージを共有
        • 処理行う DB インスタンスと、クラスターボリュームで構成
    • クラスターボリューム
      • クラスターのデータを管理するストレージ
      • 3つの AZ に2個ずつ、計6個のコピーを作成
    • クォーラムモデル
      • レプリケーション管理方法の1つ
        • 書き込み処理
          • 6個中4個が成功したら成功レスポンス
        • 読み込み処理
          • 6個中3個が成功したら成功レスポンス
  • 独自機能
    • Aurora レプリカ
      • プライマリインスタンス
        • 書き込みを受け付けるインスタンス
      • Aurora レプリカ
        • レプリカ1つで、可用性向上と読み込み性能向上の両方の役割を持つ
          • 通常時は読み込み処理を行う
          • プライマリインスタンスの障害時にフェイルオーバーし、書き込み処理をこなう
        • 複数の Aurora レプリカを作成し、読み込み処理を分散できる
    • ストレージの自動管理
      • ストレージタイプと容量を指定する必要がない
      • クラスターボリュームは、データ量に応じて自動的に増加する
        • 最大128TBまで増加する
    • 自動バックアップ
      • 設定した保持期間分、継続的かつ増分的に取得される
        • 1〜35日
      • 保持期間中のある時点へ任意に復元できる
      • バックアップデータは S3 に保存される
    • スナップショット
      • 35日を超えてバックアップしたい場合に使用する
  • その他の独自機能
    • 複数リージョンにまたがるグローバルデータベース
    • 2つのプライマリインスタンスを持つマルチマスタークラスター
    • インスタンスのサイズ指定が不要な Aurora Serverless
    • S3 と連携したファイルエクスポート、インポート機能

Aurora はいわゆる NewSQL のデータベースだ。さまざまな機能を詰め込んだ最強データベースくらいの認識でいる。RDS よりもコストは高いがかなり高性能で、とりあえず Aurora に載せ替えてしまって良いと認識している。

Amazon DynamoDB とは

DynamoDB

  • DynamoDB
    • key-value 型のデータベース
      • 高速なデータの取り出しが可能
      • 複雑な検索には不向き
  • サーバーレス
    • テーブル名とプライマリキーを指定するだけで利用可能
    • サーバー管理を意識する必要はない
      • インスタンスの作成
      • テーブル操作のリクエスト
  • テーブル
    • レコードの集合体
  • レコード
    • 格納するデータ
  • 属性
    • レコードのキーと値のセット
  • プライマリキー
    • レコードを一意に特定できる属性
  • 課金方式
    • 予約制
      • プリビジョニング済みキャパシティモード
        • 「1秒間に何回、読み・書きのリクエストを受け付けるか」を指定する
        • 予約量を超えるとエラーを返す
        • Auto Scaling で予約量を自動的に変更できる
    • 従量制
      • オンデマンドキャパシティモード
        • すべてのリクエストを処理する
        • 処理されたリクエスト数に対して料金を支払う
  • 処理量
    • キャパシティユニット
      • RCU (Read Capacity Unit)
      • WCU (Write Capacity Unit)
  • 利用料金
    • リクエスト数
    • テーブルのデータ容量

保守

  • メンテナンス
    • データのメンテナンスに集中できる
      • 利用者の所有物はテーブルのみ
      • データ操作やバックアップは AWS 側が行う
  • 冗長化
    • DynamoDB のデータは、3つの AZ へリアルタイムに複製される
  • バックアップ
    • ポイントインタイムリカバリ (PITR)
      • リアルタイムのバックアップ機能
      • 有効にすると、過去35日間の任意の時点にテーブルのデータを戻せる
    • 手動バックアップ
      • 任意の時点で手動でバックアップを保存する
      • 無期限に保管できる

データがデフォルトで3つの AZ へ冗長化されている。S3 と同じ匂いを感じる。

利用シーン

  • 処理速度が強み
    • 1日に10兆件以上、毎秒2,000万件以上のリクエストを、0.0何秒で処理できる
  • 向いているケース
    • データのやり取りが非常に多い
    • ユーザーへの高速な応答が必要
  • 具体的なケース
    • モバイル、ゲーム、広告、IoT などのアプリケーション
      • IoT 技術を利用した車両の位置追跡システム
      • オンラインゲームのランキングシステム
      • Web 広告のクリック数管理

Key-Value ストアで計算量が極端に少なく、レスポンスが高速だ。反面スキーマはなく、データの関係性を管理することには不向きだ。イベントソーシングのイベントの保存などに活用していきたい。

Amazon Redshift とは

  • Redshift
    • データの分析に使用するデータウェアハウスサービス
      • データの読み込みに特化
    • 他の場所にある大量のデータを取り込み、データの分析を行う
      • S3 や RDS などから
      • データエンジニアやデータサイエンティストが
      • SQL や BI ツールを使用して
  • 列指向ストレージ
    • データを列ごとに保存する構造
      • 例えば、平均点を計算するときに高速
  • リーダーノード
    • SQL 接続を受け付けるノード
  • コンピュートノード
    • ストレージの役割を果たすノード
    • SQL 文の実行を行うノード
  • RA3
    • 最新の Redshift のノードタイプ
      • 実データを S3 バケットに持つ
        • 利用者からは見えない
      • キャッシュデータをコンピュートノードに持つ
  • COPY コマンド
    • 1件ずつのデータ挿入は推奨されない
      • データの読み取りに特化しているため
    • 外部サーバーから、複数のテキストデータを並列アップロードすること推奨される
      • S3 バケット、DynamoDB、EC2

主にエンタープライズ領域で、大企業が活用するイメージがある。用途も業務用アプリケーションというよりかは、データ分析が主戦場である認識だ。

AWS におけるデータベース移行

  • データベース移行の重要性
    • ケース
      • アプリケーションをオンプレミスから AWS へ移行する
      • 利用するデータベースエンジンを異なるものに変更する
    • 課題
      • データ量が多いほど、転送に時間がかかる
      • 移行中はアプリケーションからの更新を止めないと、移行元と移行先でデータ不整合が発生する
      • 異なるデータベースエンジンへの移行は、互換性や網羅性の確認が必要
  • AWS Database Migration Service
    • DMS
      • データベースを移行するためのサービス
      • 様々な方式の移行が可能である
        • データの変換を伴う移行
        • 移行中に発生した移行元のデータ変更に追従する移行
        • 複数データベースを1つに集約して移行
      • 移行後に正しく移行できたか検証する機能もある
    • 移行元
      • RDS、DocumentDB、EC2、S3、オンプレミスのサーバーなど
    • 移行先
      • RDS、DynamoDB、Redshift、EC2、S3、オンプレミスのサーバーなど
    • 利用料金
      • DMS のインスタンスサイズ
  • AWS Schema Convertion Tool
    • SCT
      • データベースエンジンの移行によるスキーマ変換を行うサービス
      • スキーマ変換の評価レポートを作成する機能がある

その他のデータベースサービス

  • Amazon ElastiCache
    • インメモリデータストアを提供するサービス
      • 0.001秒未満の読み・書き速度
      • サーバーを停止すると、メモリ上のデータはすべて消える
    • Memcached と Redis に互換性あり
  • Amazon MemoryDB
    • データの永続性を確保しつつ、高速な読み書きを実現するサービス
    • ElastiCache との比較
      • サーバーを停止してもデータは消えない
      • ElastiCache よりは書き込み処理が遅い
        • 書き込みは0.00数秒かかる
  • AmazonDocumentDB
    • ドキュメント指向データベースを提供するサービス
      • 文書データの格納に長けている
      • データを JSON 形式で保管し、内容を検索することができる
    • MongoDB と互換性あり
  • Amazon Nepture
    • グラフデータベースを提供するサービス
    • グラフ構造
      • ノード
        • 1つひとつのデータを表す
      • リレーションシップ
        • 関係を表す
      • プロパティ
        • ノードとリレーションシップの内容を表す
  • Amazon Quantum Ledger Database
    • 台帳データベースを提供するサービス
    • ジャーナルの変更履歴を次々と記録していく
      • ログデータ
  • Amazon Managed Blockchain
    • ブロックチェーンネットワークを提供するサービス
    • 分散台帳技術の一種
  • Amazon Timestream
    • 時系列データベースを提供するサービス
      • センサーデータなどの処理に適している
    • 時系列データの平滑化、近似、補完機能を用いた分析ができる
    • RDB の最大1,000倍高速で、1日あたり何兆ものイベントを処理できる

Amazon MemoryDB、ElastiCache と DynamoDB の中間のようなサービスがあったとは。

Chapter7 セキュリティ、アイデンティティサービス

重要なセキュリティ、AWS の特徴でもあるアイデンティティサービスについて紹介されている。

AWS におけるセキュリティ

  • 情報セキュリティ
    • 保持している情報を安全に保つ考え方
  • 情報セキュリティの3要素
    • 機密性
      • 情報が漏洩しないよう管理すること
    • 完全性
      • 情報が正確・最新で、欠けていないこと
    • 可用性
      • 情報を使いたいときに使えるようにしておくこと
  • さまざまなサービスを組み合わせて情報を守る

AWS Identity and Access Management とは

IAM

  • IAM
    • AWS サービス利用の権限管理を行うサービス
      • サービスに権限を与えたり、一時的な権限の付与もできる
      • ユーザーを作成し、権限を付与する

IAM ユーザー

  • IAM ユーザー
    • 利用者が AWS を操作するために使用するユーザー
    • 認証情報を使ってログインすると（認証）、IAM ユーザーに割り当てられた権限を利用できる（認可）
  • アクセスキー
    • IAM ユーザーの認証情報
    • アクセスキーを通して、IAM ユーザーをプログラムに使わせることもできる
  • IAM グループ
    • IAM ユーザーをまとめて管理するグループ

IAM ポリシー

  • IAM ポリシー
    • 権限設定として「どのサービスの、どの機能に対し、何の操作ができるか」を定義したもの
  • マネージドポリシー
    • AWS が作成した IAM ポリシー
    • AWS の日々の機能追加の中で、AWS 側で IAM ポリシーを更新してくれる
  • カスタムポリシー
    • 利用者が作成した IAM ポリシー

IAM ロール

  • IAM ユーザーのアクセスキーの課題
    • アクセスキーを発行し、AWS サービスに権限を付与することができる
    • アクセスキーは固定の文字列であり、漏洩すると悪用されるリスクがある
      • 「所有に基づく認可」である
  • IAM ロール
    • AWS サービスや IAM ユーザーに一時的に権限を与える
      • 一時的に IAM ポリシーを付与する
      • AWS サービスには、IAM ロール経由で IAM ポリシーを付与する
    • 事前に「誰に付与するか」を設定し、利用時に認証を行う
      • アクセスキーのように「何らかの情報を知っていれば利用できる」わけではない
  • システムごとの AWS アカウント分離
    • 環境の分離、管理の分離、課金の分離の観点から、AWS が推奨している
  • スイッチロール
    • システムごとの AWS アカウントの IAM ロールを、IAM ユーザー利用時に割り当てる
      • 課題
        • システムごとの AWS アカウントすべてに、利用者個人の IAM ユーザーを作成することは大変
      • 解決
        • システムごとの AWS アカウントでは IAM ロールを作成する
        • 利用するたびに都度 IAM ロールを IAM ユーザーに付与する
      • 疑問
        • AWS アカウントをまたいで、IAM ユーザーを使用することができる...？
          • IAM ユーザーのクロスアカウントアクセスが設定できるらしい[6]

IAM ポリシーと IAM ロールを使用して、ユーザーや AWS リソースに権限を割り当てていく。基本的に AWS リソースは IAM ルールで良い認識。

AWS CloudTrail とは

  • CloudTrail
    • AWS アカウント作成時から自動ですべての操作を記録するサービス
    • 誰がどういった操作をしたのか調査に役立つ
  • 証跡 (ログ)
    • 自動的に90日間は保存される
    • S3 に保管することもできる
      • 暗号化されて保管される
      • 保管後にログの改ざんを防ぐ機能もある
  • 記録される操作
    • マネジメントコンソールや API 経由の操作
      • 管理イベント
        • マネジメントコンソールへのログイン
        • AWS リソース自体の作成・変更・削除
      • データイベント
        • AWS リソースのデータへの操作
      • インサイトイベント
        • 普段と異なる AWS アカウントの異常な操作
  • 記録されない操作
    • EC2 インスタンスにログインして EC2 インスタンス内で行う操作
  • 証跡の出力
    • S3
      • ファイルとして保管
      • 改ざん判定の機能を利用できる
    • CloudWatch Logs
      • ストリームで保管
      • リアルタイムに確認したり、内容を検索したりできる
  • 基本的に有効にしたい

こんなサービスがあったのか。頭の片隅に置いておきたい。

AWS Config とは

  • AWS Config
    • AWS リソースの設定情報と変更履歴を記録するサービス
    • デフォルトで7年分の情報が保存される
  • 高度なクエリ
    • SQL を用いてリソース数などを検索できる
  • AWS Config ルール
    • AWS 内の各設定がルールに準拠しているか判定する機能
    • マネージドルールとカスタムルールがある
  • 他サービスとの連携
    • Amazon EventBridge、Amazon SNS
      • 非準拠のリソースを利用者へメール通知
    • AWS System Manager - Automation
      • 非準拠のリソースを自動修復する機能
  • 利用料金
    • 設定項目数
  • 基本的に有効にしたい

こちらも初めて知った。AWS Config により、インフラのリソースに対してリントを実行することができるイメージだ。

AWS GuardDuty とは

  • GuardDuty
    • AWS 上で発生する脅威を検出するサービス
      • 不正な動作や悪意のある操作
    • 検知の仕組みは AWS 側が管理する
  • 判定元の情報
    • CloudTrail
      • 不正な AWS リソースの操作がないか
    • VPC フローログ
      • 不正な VPC 通信がないか
    • DNS Logs
      • 不正な DNS 通信がないか
  • サンプルイベント
    • 検知内容を確認するために、試験的なイベントを発行する機能
  • AWS アカウント開設後にすぐに有効化する

こちらも初めて知った。脅威検知の仕組みがあり、デフォルトでは無効のようだ。活用していきたい。

まとめると、以下の3つのサービスは、もし有効でなければ有効にしてしまって良さそうだ。

  • AWS CloudTrail
  • AWS Config
  • AWS GuardDuty

AWS WAF とは

  • WAF
    • Web アプリケーションファイアウォールのマネージドサービス
    • Web アプリケーションの脆弱性を突いた攻撃を検知し、不正なリクエストを無効化する
  • ウェブ ACL
    • リクエストに対して制御したいルールを設定する
    • 対象の AWS サービスに適用する
      • たとえば、前段の ELB に適用し、配下の EC2 を保護する
      • CroudFront や API Gateway などにも適用できる
  • WAF ルール
    • カスタムルール
      • 利用者が設定する WAF ルール
      • IP 制限や正規表現によるフィルタリングなど
    • マネージドルール
      • AWS 側で管理される WAF ルール
      • SQL インジェクションや XSS なども含まれる
    • サードーパーティルール
      • Amazon Marketplae 上で販売される WAF ルール

今時の Web アプリケーションであれば、とりあえず WAF を設定してしまって良い認識だ。

その他のセキュリティ、アイデンティティサービス

  • AWS Network Firewall
    • VPC をまたぐ通信に対し、ファイアウォール機能を提供するサービス
    • オンプレミス環境からのファイアウォール設定の移行がしやすい
  • Amazon Inspector
    • 静寂性管理を行うサービス
      • 特に EC2 は利用者の自由度が高く、インスタンスの静寂性管理が大変
    • あらかじめ評価ルールが用意されている
      • 「一般公開されているソフトウェア脆弱性に合致するものはないか」
      • 「AWS のセキュリティのベストプラクティスを満たしているか」
  • AWS Shield
    • DDoS 攻撃を防ぐサービス
      • AutoScaling によるコスト増を防ぐ
    • 2つのプラン
      • Standard
        • 無料で自動的に有効化される
      • Advanced
        • AWS の DDoS 対策専門チームのサポートを受けることができる
        • ただし、かなり高額である
  • AWS Security Hub
    • AWS アカウント全体に対してセキュリティのベストプラクティスのチェックを行うサービス
      • PCI DSS
        • クレジットカード情報セキュリティの国際統一基準
      • CIS AWS Foundations Benchmark
        • 団体標準の AWS アカウントの基本的なセキュリティプラクティス
      • AWS が定める推奨設定
  • Amazon Cognito
    • Web アプリ・モバイルのユーザー認証・認可を行うサービス
    • ユーザー認証機能
      • ID・パスワード認証
      • 多要素認証
      • パスワード変更機能
    • 認可機能
      • 認証されたユーザーに IAM ロールを与える
  • AWS Directory Service
    • AWS 上でマイクロソフトの Active Directory を利用するサービス
      • ユーザー管理システム

Chapter8 知っておきたいその他のサービス

AWS が今後力を入れていくであろうサービスが紹介されている。

データ分析サービス

  • データ分析とは
    • 新たな知識発見や意思決定サポートを行うために、蓄積されたデータから規則性や傾向を探し出すこと
    • リアルタイムのデータを素早く分析し、データを加工し、データを可視化することも役割の1つ
  • データの保管
    • データレイク
      • 分析に使うデータを溜めて置く場所
      • AWS では基本的に S3 を使用する
    • 生データ
      • 送られてきた未加工のデータ
    • データウェアハウス
      • 分析に適した加工済みデータを格納して置く場所
  • Amazon Athena
    • S3 のデータを SQL で分析できるサービス
      • S3 ファイルのデータ構造をあらかじめ Athena に登録しておく
      • S3 ファイルのデータ構造が決まっていれば、手軽に集計や検索できる
  • AWS Glue
    • 前処理の ETL 処理を簡単に自動化するサービス
      • データの抽出・変換・格納
  • Amazon OpenSearch Service
    • OpenSearch という全文検索サービスを簡単に展開できるサービス
      • Elastichsearch を元に AWS が開発
    • データを登録すると、自動的に検索用データ（インデックス）を作成する
  • Amazon EMR
    • 分散フレームワークを AWS 上で動かすためのサービス
      • Apache Spark や Apache Hadoop
    • ビックデータ分析では、データの膨大さから分散処理する
  • Amazon QuickSight
    • 登録されたデータの可視化を提供するサービス
      • 機械学習によるデータの特徴発見、今後のデータ変動予測を行う機能もある
      • 自然言語クエリという機能もある
  • Amazon Kinesis
    • リアルタイムでデータを処理するためのサービス
    • Kinesis Family
      • Kinesis Data Streams
      • Kinesis Data Firehose
      • Kinesis Data Analytics
      • Kinesis Video Streams

機械学習サービス

  • 機械学習の手法
    • 教師あり学習
    • 教師なし学習
    • 強化学習
  • ディープラーニング
    • コンピューターが自律的に学習精度を高めていく手法
  • Amazon SageMaker
    • 機械学習の実行環境を提供するサービス

筆者はあまり縁がなく、かなり簡潔にまとめてしまった。

マネジメントサービス

  • システムマネジメント
    • システムがサービスを開始してからシステムを維持していくための作業
  • AWS CloudFormation
    • AWS リソースをテンプレートで管理し、構築できるサービス
      • JSON か YAML のファイル
    • テンプレートと実設定の差分検出機能もある
  • Amazon CloudWatch
    • CloudWatch
      • AWS サービスのメトリクス、ログを監視し、可視化するサービス
    • メトリクスとは
      • AWS サービスから登録されるデータの集合
      • 各サービスの稼働状況を示すデータ
        • CPU 使用率やアクセス数など
    • 標準メトリクス
      • 自動で登録されるメトリクス
    • カスタムメトリクス
      • 独自に登録するメトリクス
      • CloudWatch エージェントや API 経由で登録する
    • アラーム
      • メトリクスが閾値を超えたら通知する機能
    • CloudWatch Logs
      • ログを一元的に管理し、ログを監視する機能
  • AWS System Manager
    • EC2 の管理を行うためのさまざまなサービス
      • Session Manager
        • セキュリティグループの許可なしでサーバーにログインできる
      • Inventory
        • サーバーにインストールされているソフトウェアを一覧表示する
      • Patch Manager
        • OS やミドルウェアのパッチ適用を管理する
        • 重要度などの条件を設定して、自動的にパッチ適用することもできる
      • Parametor Store
        • 複数のサーバーで共有したい情報を格納する
        • 最大8kbの文字列を保存できる
      • Documents
        • EC2 への操作内容を保管する
          • Run Command
            • 1つの Documents を実行する
          • Automation
            • 複数の Documents を実行する
          • State Manager
            • 定期的に Documents を実行する
            • サーバー状態を一定に保つ
    • 一部機能の利用には SSM エージェントのインストールが必要
  • Amazon Code シリーズ
    • アプリケーションソースコードを管理するためのサービス
      • CodeCommit
      • CodeBuild
      • CodeDeploy
      • CodePipeline
      • CodeStar

Amazon CloudWatch は多機能であるため、あらためて学ぼうと考えている。

コラム

AWS の利用料を理解する

  • リソースの確保
    • AWS のリソースを占有している時間に対し、料金が発生する
      • AWS のリソース
        • CPU、メモリ、ディスク領域
      • インスタンス稼働
        • EC2 や RDS は、インスタンス稼働中はずっと料金が発生する
      • サーバーレス
        • Lambda や Fargate は、利用されるときだけリソースが確保される
  • データの保管
    • AWS 上に保管されているデータ量に対し、料金が発生する
      • あらかじめ保存できる容量を決めて、容量を確保するタイプ
      • データ量に応じて、容量が自動的に確保されるタイプ
    • 忘れがちだが、バックアップの保管に対しても、料金が発生する
  • 処理量
    • リクエストの処理数や処理したデータ量に対して、料金が発生する
      • ネットワーク、コンテンツ配信
        • Route 53、ColudFront
      • セキュリティ、マネジメント
        • CloudTrail、AWS Config
      • リクエストを受けて動作するサービス
        • Lambda、S3
  • データ転送
    • データ転送に対して、料金が発生する
      • ネットワークサービス
        • Site-to-Site VPN、Direct Connect
      • インターネット通信
        • EC2、S3
      • VPC 通信
        • AZ やリージョンをまたぐ通信
        • VPC ピアリングの通信
  • 無料利用枠
    • AWS アカウント作成から12ヶ月のみ使えるもの
    • 対象のサービスを初めて使ってから一定期間使えるもの
    • 各サービスで常に一定の利用量まで無料とされているもの

コラムとして掲載されていた。利用料の大枠を掴むことができる。特にデータ転送量に関しては実際の量をイメージしづらく、またサブ的に課金されるサービスも多いことから、見落としがちだ。初期の見積もりは難しいかもしれないが、AWS Cost Management のダッシュボードを眺めて最適化していきたい。

終わりに

いかがでしたでしょうか。本の内容を理解しながらマインドマップにまとめるのに2日、記事化するのに1日ほどかかってしまいました。

深掘りを行ったセクション

まず、特に深掘りしたセクションを次に示します。読み物としておすすめです。

次に、記事の内容だけでなく、コメントを付与したセクションの一覧を載せておきます。

知れてよかったこと

AWS 謹製の設計のお手本フレームワークを知れました。

AWS の学習方法を体系的に整理できたのはありがたかったです。

AWS のセキュリティサービスにおいて、以下の3つは AWS アカウント作成後に有効にしてしまって良いと掴めました。

  • AWS CloudTrail
  • AWS Config
  • AWS GuardDuty

その他、AWS や AWS サービスの裏側を多数知れたことは、知的好奇心を満たすとともに喜びが大きいものでした。

以上となります。最後までお付き合いただきありがとうございました！

参考文献

脚注

  1. AWSサブネットの切り方を考えてみた | DevelopersIO より ↩︎

  2. AWS サブネットで利用可能なIPアドレス数について より ↩︎

  3. Amazon VPCとサブネットの設計のポイントについて - サーバーワークスエンジニアブログ より ↩︎

  4. Google Pro Tip: Use Back-of-the-envelope-calculations to Choose the Best Design - High Scalability より ↩︎

  5. How fast should a website be 🤔 より ↩︎

  6. IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 ↩︎

Discussion