ELB、CloudFront、専用線周りのサービス
ELB
例えば、負荷分散などを目的とした場合サーバを複製することがある
問題点もある
- アクセスポイントが分かれてしまう
- 片方が落ちた場合、落ちた方にはアクセスさせたくない（異常を検知したい）
そこで役に立つのがELB
簡単に言うと「外部/内部向けのロードバランサー」
簡単な使い方
DNSでユーザーからのアクセスをELBに向けてあげる
メリット
AutoScalling
AutoScallingを利用（連携）すると、負荷に応じたサーバの増減ができるようになる
ヘルスチェック
定期的にELBから通信してレスポンスの状態を確認
ELBにぶら下がっているサーバの死活監視のようなものをしてくれる
証明書の付与
セキュリティの問題からHTTPS通信が基本となっている
そのためには証明書が必要だが、その証明書をELBに付与させることでELBより次の通信は暗号化処理を行えるようになる
⇨ 暗号化処理をELBで請負のサーバ負荷が下がる（SSLターミネーション）
種類
ELBには種類がある
ALB L7レイヤーでのロードバランサー（アプリケーションレイヤー）
NLB L4レイヤーでのロードバランサー(ネットワークレイヤー)
（※CLB 古いELB特別な理由がなければ基本的には使わない）
⇨ NLBの方が処理速度が早い
ELBに関する用語
| 用語 | 内容 |
|---|---|
| リスナー | プロトコルやポートを設定 |
| リスナールール | HPPヘッダー、ソースIPが〇〇だったらのようなルールを設定。デフォルトはターゲットグループへ転送 |
| ターゲットグループ | E C 2,Lambda,IPアドレスなど宛先をグループ化 |
| ヘルスチェック | 管理しているサーバ等の死活監視 |
| アクション | 振り分け前に何か処理を挟む。例）リダイレクト、転送、Cognito認証、OIDC認証 |
通信の流れ
ALB(SG) →
リスナー（何で待ち受けているか） →
リスナールール(パスが〜〜 ソースIP〜〜)優先度が設定できる →
アクション（ユーザー認証できるかどうか、ターゲット） →
ターゲットグループ(ターゲットを管理してくれる) →
各ターゲット
スティッキーセッション
クッキー : 閲覧履歴などの接続情報がブラウザに保存されている
問題点 : セッション情報の管理元(サーバ)が異なるとクライアント側と整合性が取れない
→ スティッキーセッション、確実に特定のターゲットにのみ振り分けることができるようにする（クッキーに接続情報を与える） LBがクッキーを読んでくれて振り分けることができる
期間ベース：ALBがクッキーを生成
アプリケーションベース：アプリ側がクッキーを生成
セッションストア
どこか別のところでセッションを保持すること
セッション情報ID ⇨ クッキーに保存 ⇨ セッション情報とクッキーで誰がきたかわかるようにする
セッション情報をサーバ側で持たせてしまうと障害が起こった時には、不具合につながる(なるべくサーバにはセッション情報を持たないでおこう)
セッション情報を外部で持つことが推奨される（DynamoDB,Amazon ElastiCacheなどが使われる）
Route53
AWSが提供するDNSサービス
※ 独自ドメインをRoute53で購入できる（高い）
ルーティング一覧
| 項目 | 内容 |
|---|---|
| フェールオーバールーティング | Route53がドメインに対してヘルスチェックを行なってくれる ⇨ 仮にアクセスができない状態だった場合は他へ（Sorryページ）と振り分ける処理を行うことができる |
| シンプルルーティング | 一つのリソースに対してシンプル解決な名前解決 |
| 加重ルーティング | 複数のリソースに対して、何％ずつルーティングするか |
| レイテンシールーティング | レイテンシーを判断して、振り分けるルーティング |
| 位置情報ルーティング | クライアントの位置情報を見て振り分けるルーティング |
| 複数値回答ルーティング | 複数のリソースに DNS レスポインスを分散する場合に使用。たとえば、複数のルーティングレコードを Route 53 ヘルスチェックに関連付ける場合 |
レコード一覧
レコードとは
名前解決にきたドメインが何を紐づているかルール表みたいなもの
| 項目 | 内容 |
|---|---|
| Aliasレコード | AWSリソースを紐づける |
| Aレコード | IPアドレス |
| AAAAレコード | IPv6アドレス |
| NSレコード | ドメイン情報を管理するサーバ。ネームサーバ |
| SOAレコード | ドメインの管理情報 |
| CNAMEレコード | ドメインとURLの紐付け。Aliasレコードと似ているがAliasレコードの方を推奨 |
ホストゾーン
レコードをまとめてドメインで管理する単位
CloudFront
AWSが提供するCDNサービス (他だったらAkamaiが有名)
CloudFronthaエッジロケーションでの稼働
特徴
キャッシュ
CloudFrontではコンテンツをコピー(キャッシュ)することができる
⇨ サーバからの処理がなくなるため、高速化＋サーバの負荷軽減になる
連携
例えば、ACM AWS WAFと各種連携できる
コンポーネント
| 項目 | 内容 |
|---|---|
| Viewer | クライアントのこと |
| Origin | EC2 S3 LBなど様々 |
| Behavior | 振る舞い。CloudFrontにどういった処理や振り分けルールなどを設定 |
| キャッシュポリシー | TTLの設定 |
TTLの設計が大事
どのデータを何秒間キャッシュ（保持）しておくかが大事
データが古すぎたりするといけないデータや、変化の激しいデータはキャッシュが長いと意味がない(向いていない)
逆に重要にならないようなデータなどが向いている
静的コンテンツの配信
S3 ± CloudFrontで静的コンテンツの配信が可能になる
⇨ 署名付きURLを発行することができ、一定期間だけ配信したいなどの対応も可能
【問題点】
S3 ± CloudFrontで静的コンテンツの配信を するということはS3をパブリックに配信している
⇨ デフォルトのままだと、直接S3エンドポイントを叩けば、CloudFrontを通さないようになってしまう
この問題を解決するのが
「OAI(Origin Access Identity)」
⇨ OAI S3に直接アクセスさせない仕組み (CloudFrontを必ず通るようにする仕組み)
※ OACというよりセキュリティ強化されたサービスもあったりする
CloudFrontを経由したテストの時はTTL「０」にしておくことがオススメ。
CloudFront設定詳細
Cloud Frontを利用するまでの簡単な流れ
- オリジン用意 ⇨ EC2、Lambda、S3など
- ディストリビューションの作成
- ディストリビューションにドメイン割り当て
- ディストリビューションの設定がエッジロケーションに送信
Cloud Front通信
※ キャッシュがある場合は2,3の流れが不要になる
料金
※ ① ② ③ の番号が割り当てられているところで通信があれば料金が発生する
Behavior
Behavior(ビヘイビア)はCloudFrontにどういった振る舞いをするかなど動作設定を行う
- キャッシュの動作（キャッシュの有効期限、キャッシュしないオブジェクトの指定、等）
- セキュリティ設定（署名付きURLの使用、許可されたHTTPメソッドの指定、等）
- エラー処理（エラー時の挙動の指定、等）
- リクエストのルーティング（オリジンサーバーの選択、パスのリライト、等）
「HTTP圧縮」
コンテンツを配信する際にCloudFront側でコンテンツを圧縮して以下２点が見込まれる
・通信速度が早まる
・通信容量の削減
※ br, gzipがあれば
「ビュアープロトコルポリシー」
プロトコルによって挙動を変える
⇨ HTTPとHTTPS通信させる
⇨ HTTPが来たらHTTPSにリダイレクトさせる
⇨ HTTPSのみ
「HTTPの許可」
HTTPメソッドを設定できる
例） DELETEさせたくないとか、GETだけにさせるとか
「キャッシュキー」
キャッシュヒット率高い＝オリジン負荷が少ない
キャッシュキーをCloudFrontが保持する
⇨ 同じものが届いたことをCloudFrontが確認するとCloudFrontがそのままコンテンツを返す
GET Hostヘッダー以外に追加でキャッシュキーに他の情報を含めまることができる
⇨ 追加情報のおかげで少しでも違いがあると、新しいコンテンツを配信できるようになる
⇨ あまり色々キャッシュキーを含めると逆にキャッシュヒット率が低くなってしまう
「オブジェクトキャッシュ」
コンテンツのキャッシュをコントロール(どれぐらいの時間保持)できる
例） S3のメタデータの編集で「Cache -Control」という項目がある ⇨ use origin だとオリジン側のキャッシュを優先
⇨ カスタマイズ
Minimum TTL ⇨ 最小秒数
Maximun TTL ⇨ 最大秒数
デフォルト TTL ⇨ オリジンがTTL設定されていない時の秒数
これまでの動作はパスの一つ一つに結びつくため
パスが大量にある場合設定が煩雑になってしまう
⇨ これを解消するためにあらかじめAWSが（オススメの）キャッシュポリシーを用意してくれている
AWS VPN
VPNとはインターネット回線にVPNトンネルを構築してトンネル内の通信を暗号化して通信する技術
ClienttVPN
ローカルPCからVPCへ接続するようなVPN
ローカルPCのVPNソフトウェアを使用してVPCにVPN接続できる
ClientVPN Endpoint （ENIで接続）をすることで通信をすることができる(HTTPS通信)
SitetoSiteVPN
オンプレミスからVPCへの通信経路。オンプレミス側にVPNルーターを設置してそこからVPN接続を行う。
オンプレミス側にはCustmer Gatewayを設置する。これはユーザー側で用意するルーター。
AWS側ではVPCにVGWを設置して通信をできる口を作る
ルーティングの設定を行うことでオンプレミスとVPC間でPraivateIPでの通信が可能になる。お互いにルーティングの設定を行う
特徴
バックアップの経路
オンプレミスとVPCを接続させるときに専用線接続がある。
専用線もなんらかしらの障害によって通信ができない可能性が０ではない。
なので専用線接続が障害が起きたとしてもVPCへの接続ができるようにバックアップ回線（VPN）をVPCと引いておくことが回線の冗長化に繋がってくる
コンポーネント
「ASN」
大規模なネットワークを管理している企業。それぞれにASNナンバーがある
「BGP」
AS同士の通信を管理するプロトコル
「CloudHub」
AWSが提唱する設計モデルのこと
オンプレミスの拠点同士をAWS経由で接続できるようになる
Direct Connect
インターネット経由ではなく専用線でAWSと接続ができるサービス
専用線なので帯域幅を確保できる ⇨ 通信が安定できる
概念
Direct ConnectロケーションというAWSネットワークと接続できるデータセンターがある
そこには、Direct Connectを引きたい側の「ユーザーラック」とAWSネットワークに繋がる「AWSラック」の両方がある
ユーザー側のラックにはユーザー自身で管理する場合とAPNパートナーで管理する2つのパターンが存在する
専用の接続するときにユーザーラックとAWSラックの間の別途専用の接続を行う必要があって、この接続を「クロスコネクト」という
コンポーネント
| 項目 | 説明 |
|---|---|
| VIF | 仮想インターフェースのこと |
| Praivate VIF | 上記VIFの概念。VPCと繋ぐ場合にVGWに向かって接続するPrivateなVIF |
| Public VIF | S3、DyanamoDBなどVPC外のサービスと繋ぎたい場合に利用する |
| ※ お客様DCのVLANはVIFごとに設定できる |
DXが提供されるときに2種類のオプションがある
「占有型」
1回線分丸ごとユーザーに提供できる。とてもリッチな分高額な回線
自由度が高い（VIFを自由に設定できる）
「共有型」
APNが所有するDX回線の一部を借りる(複数人で共有する)
占有型に比べると安価
各アカウントごとのVIFを割り当てる
注意点
DXはデフォルトでは通信経路は暗号化はされていない
別途、VPNトンネルを作るなどして暗号化している環境を作る必要がある
Direct Connect Gateway
複数リージョンとDirect Connectロケーションを接続するサービス
※ DX GWを跨いだVPC間の接続はできない
TransitGateway
複数VPCなどを繋ぐためのHUBのようなAWSサービス
例えば、TransitGatewayを利用しないでVPC間を繋ごうと思うとピアリング接続が多くなり、ルーティングの管理がかなり大変な状況になる
それを一括でTransitGatewayがルーティングの管理をしてあげることでスッキリする
Direct Connectとの接続
Direct ConnectとTransitGatewayを繋ぐことができて、オンプレミスからの接続も集約することができる
(下記画像のような構成のように間にDXGWが必要となる。Transit VIFも必要)
コンポーネント
| 項目 | 内容 |
|---|---|
| アタッチメント | VPCとTGを関連づける（アタッチしただけなの通信は不可） |
| ルートテーブル | 通信を制御する経路情報。ルーティングの情報 |
| アソシエーション | ルートテーブル(TG)とルートテーブル(VPC)の関連づけ。1つVPCについて1つアソシエーションが振り分け可能（アタッチしてからアソシエーション） |
| プロパゲーション | VPCからの経路情報を伝搬すること。ルートテーブルの中に書いているルーティングみたいなもの |
| スタティックルート | 静的ルート。アソシエーションしている必要がない |
Global Accelerator
リージョン単位での振り分けが可能になるサービス
（マルチリージョンで負荷分散ができる）
Global Accelerator1つに対して1つのエンドポイントグループを付与して利用する
ユーザーが稼働しているエッジロケーションにアクセスする仕組み
特徴
インターネット回線よりも早い。
これはAWSのネットワークを使うことによってインターネット経由(例えばCloudFront)よりも早くできる
※ エンドポイントの監視、UDP対応してない
まず前提としてAWSのリージョンは、中国リージョンを除く各リージョンの間はAWSのプライベートネットワークで接続されています。つまり、AWSのリージョンからリージョンの通信が、インターネットを経由することなくAWSが管理するネットワークを通るということです。なお、集合体の事をAWSのグローバルネットワークと読んでいます。これが、先ほどの「インターネットのトラフィックをAWSが保有するグローバルネットワークを通じて」が言及している部分になります。
参考資料
Discussion