AWS_SAA取得に向けて(Part1)
インフラ構成とネットワーク
サブネット:
EC2インスタンスなどを起動するためにVPC内部に作るアドレスレンジ。
VPCとサブネットについて
CIDR :
Classless Inter-Domain Routing(CIDR)は、インターネット上のデータルーティング効率を向上させるIPアドレス割り当て方法。
任意のサブネットマスク値を使うことによってネットワークの大きさを変えられるようにしたのがCIDR。
ルートテーブル :
VPC内(サブネット内)の通信を振り分けるルールの一覧こと。
サブネットごとにもつ。
設定していない場合はVPCのメインテーブルが適用される。
★VPCの通信制御はセキュリティーグループ+ネットワークACLで行う
セキュリティグループ:
EC2やELB、RDSなどのインスタンス単位の通信制御に利用する。インスタンスには少なくとも1つのセキュリティグループをアタッチする必要がある。通信の制御はインバウンド、アウトバウンド両方設定可能。
ネットワークACL :
サブネット単位の通信制御に利用する。
AWS Site to Site VPN (AWSマネージドVPN) :
VPCとオンプレミスのサービスをVPN接続するサービス。
通信はインターネットを経由するが暗号化されているためセキュリティ性は担保されている。VPCからの出口はVGW
仮想プライベートゲートウェイ (VGW):
VPCがVPNやDirect Connectと接続するためのゲートウェイ。
各VPCに1つしか存在できないが、複数のVPNやDirect Connectと接続することができる。
VPCエンドポイント :
インターネットゲートウェイと同様にVPC内からVPC外のサービスへアクセスができる。
インターフェイスエンドポイント:
一部のAWSサービスやNLBを介した独自サービス、サポートされているAWS Marketplaceサービスにプライベートに接続する
ゲートウェイエンドポイント:
S3及びDynamoDBへのアクセスをプライベートに接続する
※ゲートウェイエンドポイントの後にインターフェイスエンドポイントが作られたため利用できるサービス数には差がある。
https://dev.classmethod.jp/articles/aws-vpcendpoint-privatelink-beginner/
VPCフローログ:
VPC内の通信の解析に利用。
ENI単位で記録され送信元・送信先アドレスとポート、プロトコル番号、データ量、許可、拒否などを記録する。
AWS Direct Connect ゲートウェイ:
1つのDirect Connectの接続を利用して最大10個のVGWと関連付けることができる。
AWS Transit ゲートウェイ:
複数のVPCやDirect Connect, VPNスター型トポロジーで接続可能とするサービス。
VPCピアリングで実現できなかった3つ以上のVPC間の接続が可能。
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/direct-connect-gateways-intro.html
Q.transit ゲートウェイ一択ならVPCピアリングいらなくね?と感じたので調べてみた。
AWS ENI (Elastic Network Interface) :
VPC上で実現する仮想ネットワークインタフェース。
物理環境におけるNIC (Network Intarface Card)。
インスタンスにアタッチしたりデタッチしたりできる。
含めることができる属性(情報)は以下
・VPC の IPv4 アドレス範囲からのプライマリプライベート IPv4 アドレス
・VPC の IPv4 アドレス範囲からの 1 つ以上のセカンダリプライベート IPv4 アドレス
・プライベート IPv4 アドレスごとに 1 つの Elastic IP アドレス (IPv4)
・1つのパブリック IPv4 アドレス
・1 つ以上の IPv6 アドレス
・1 つ以上のセキュリティグループ
・MAC アドレス
★セカンダリプライベートアドレスは障害発生時に接続先を切り替える時に有効。
コンピューティングと関連サービス
ELB:
負荷分散に利用されるロードバランサー
以下の3つがあるが基本的にALB、NLBを利用する。
✅ Classic Load Balancer (CLB) : L4/L7での負荷分散を行う
✅ Application Load Balancer (ALB) : L7での負荷分散を行う
✅ Network Load Balancer : (NLB) : L4での負荷分散を行う。
HTTP(s)以外のTCPプロトコル通信の負荷分散で利用。
ヘルスチェック:
ELBが設定された周期で配下にあるEC2にリクエストを送り、正常に動作しているかを確認する機能。異常なインスタンスが見つかった時は自動的に切り離し、その後正常になったタイミングでELBに紐づける。
Auto Scaling :
EC2の利用状況に応じて自動的にインスタンスの数を増減させる機能。
Lambda:
サーバレスアーキテクチャの中核となる機能。
主要な特徴は以下の3つ。
・プログラムの実行環境を提供し、インフラ構築、管理にかける時間を短縮
・リクエスト量に応じて自動でスケーリング
・リクエスト量や実行時間に応じた課金モデル
⇒ 常にコストが発生するわけではないのでコスト最適な構成の実現に貢献
★実行可能時間は15分のため処理がこの時間以上にかかる場合は別のサービスを検討する必要がある。= timeoutが15分
AWS batch :
システムのバッチ処理(定期実行される処理)とは異なる。
利用することでバッチコンピューティングソフトウェアのインストールや管理が不要になる。
コンテナサービス:
EC2だとインスタンス単位でしか I AM ロールをアタッチできなかったが、ECSではクラスター上の task ごとに I AM ロールをアタッチできる。
EKSについてはkubeの概念の話になるので初期はAWSでpodからAWSリソースへの権限管理をする方法がなかったらしい。
認証認可の話が出てきたので調べた(OAuth)
結論両者の違いは
OAuth : 認可のためのプロトコル ⇒ APIの保護とか
OpenID Connect : 認証のためのプロトコル
ストレージ
AWSのストレージタイプは以下の3つに大別される
✅ ブロックストレージ
✅ ファイルストレージ
✅ オブジェクトストレージ
オブジェクトロック:
S3の機能で一定期間または無期限でオブジェクトが削除または上書きされることを防ぐ。
言って機関の保護を目的としたリテンションモードと保護期間を設定しないリーガルホールドの2種類がある。
オブジェクトロックはバケットに対して行う。
ガバナンスモード:
リテンションモードの1つ。
設定すると特別な許可(権限)を持たない限りはオブジェクトのバージョンの上書きや、削除、ロック設定の変更ができなくなる。
コンプライアンスモード:
リテンションモードの1つ。設定するとAWSアカウントの root ユーザ含め、誰も対象のオブジェクトに対して操作ができなくなる。
ロック設定の変更も保護期間が終わるまでできない。
MFA (Multi-Factor Authentification) Delete:
S3のデータ保護機能の1つ。
有効にするとデータ削除時にMFAのワンタイムパスワードを入力する必要があり、誤った操作によるデータ消失を防ぐ。
アクセスポイント:
S3のバケットへのアクセス制御はバケットポリシーで行う。
アクセスポイントの制御には以下の3つの方法がある。
・I AM ポリシーの利用
・VPC IDによる制限
・パブリックアクセスの管理
S3へのアップロード:
◆ マルチアップロード:
単一のオブジェクトを分割してアップロードする機能。
パートごとに並列アップロードするためネットワーク問題が発生した場合でも最小限の影響で再開、アップロードの停止が行える。
◆ S3 Transfer Acceleration :
遠隔地のS3へのデータ転送をサポートする機能。
CloudFrontのエッジロケーションを活用しており、ユーザは最寄りのエッジロケーションへアップロードする。
その後AWSの回線を利用してデータを転送する。
データベース
Amazon RDS :
AWSが提供するマネージとRDBサービス
ストレージにはEBSを使用 ⇒ ブロックストレージ
◎メリット:運用の効率化・省力化
マルチAZ構成について冗長化自体はAWS側でやってくれる。
しかし2つのAZ間で同期をとるため書き込み速度が遅くなる。
フェイルオーバー時に再接続までに時間がかかる。
プライマリのIPをスタンバイ側のIPへ変更しDNS(名前解決)を行い接続できるようになる。
リードレプリカ:
パフォーマンス向上のため参照専用のインスタンス。
マスタインスタンスとリードレプリカは非同期のためデータ整合性は担保できない。
セキュリティ:
Amazon Aurora:
他のRDSと異なりマルチAZ構成オプションは存在しない。
Auroraクラスタ内に参照専用のレプリカインスタンスを作成することができるためプライマリインスタンスに障害が発生した場合はレプリカインスタンスがプライマリに昇格することでフェイルオーバーを実現する。
エンドポイントは以下4種類
・クラスタエンドポイント
・読み取りエンドポイント
・インスタンスエンドポイント
・カスタムエンドポイント
Amazon RedShift:
AWSが提供するデータウエアハウス向けのデータベースサービス。
大量のデータから意思決定に役立つ情報を見つけ出すために必要な環境を素早く安価に準備できる。
◇DWHとDBの違い
RedShiftはデータウエアハウスの最大のボトルネック要因は I/Oを考慮し列指向 (カラムナ)データベースを採用。
パフォーマンスを最適化。
◇ 高速処理のための並列構成を実現する機能
・MPP (Massive Paralell Processing):
1つのタスクを複数ノードで分散して実行する仕組み
・シェアードナッシング:
ディスクをノード間で共有しない構成。
RedShiftのデータは各コンピュートノード内のローカルディスクに分散して格納される。
Redshift Spectrum :
S3に置かれたデータを外部テーブルとして定義できるようにし、Redshift内にデータを取り込むことなくクエリの実行を可能にするサービス。
以下の課題のソリューションとして誕生
・S3からのデータコピーに時間がかかる
・データの増加に伴うコストの増加
Dynamo DB:
Amazon Dynamo DBはAWSが提供するマネージドサーバーレスNoSQLサービス。
Key-value型を採択。
◎メリット
・単一障害点 (SPOF)を持たない。
・自動的に3つのAZに保存されるため可用性、耐障害性が優れている
スループットキャパシティの設定が可能
・Read Capacity Unit (RCU)
・Write Capacity Unit (WCU)
DynamoDb Accelerator(DAX)
⇒ RCU (Read Copy Update) の確保を抑えコスト削減にも大きく貢献
Amazon ElasticCache:
AWSが提供するインメモリ型データベースサービス。
高頻度で参照するデータや検索に時間がかかるデータセットをメモリ上に保持することでシステムのパフォーマンス向上に寄与
Memcached, Redisの2種類のエンジンから選択可能
(Redisの方が良く利用される)
✅ Memcached
key-value型インメモリデータベースのデファクトスタンダード
データの永続性がないため一時的なキャッシュとしての利用、データが消去されても問題がない場合に利用。
※デファクトスタンダード:公的な機関からの認証ではなく市場における企業間の競争によって業界の標準として認められるようになった規格のこと。
「事実上の標準」
✅ Redis
key-value型インメモリデータベース
Memcachedよりも多くのデータ型が利用可能
ノード間のレプリケーション機能やデータ永続性機能も実装
障害発生時にも対応可能!
クラスタモード:
有効化することで最大500のシャードにデータを分割して保存する構成が可能。データの分散によりRead/Writeの負荷分散が実現できる
シャード:
1つのマスタインスタンスとリードレプリカのまとまりを指す。
ここまでで見た感じ Redis 1択になる気がしたので調べてみた
データの暗号化はRedisのみ。通信の暗号化はMemcacheでも可能
◇ Others
Amazon Neptune :
フルマネージドなグラフデータサービス。
経路検索や購入履歴からのリコメンデーションに利用
Amazon DocumentDB :
MongoDB互換のフルマネージドなドキュメントデータベースサービス。サーバー上で独自に作成したMongoDBの移行が可能。
Amazon Timestream :
フルマネージドな時系列データベースサービス。
時間的に変化した情報を持つデータに特化。
RDBを利用した場合と比較して1000倍の速度でかつ低コストに処理・分析が可能。IoTやサーバモニタリングに最適。
Amazon QLDB :
フルマネージドな台帳データベース
台帳データベースサービスとは変更履歴などをすべて残し、かつその履歴を検証可能な状態にするもの。
企業の経済活動、財務活動履歴として記録する必要がある場合に適したサービス。
ネットワーキングとコンテンツ配信
Amazon Cloud Front :
HTMLファイルやCSS、画像、動画といった静的コンテンツをキャッシュし、オリジンサーバの代わりに配信する (Contents Delevery Network) サービス。
利用者から最も近いエッジロケーションからコンテンツを高速に配信する。
Q. 利用しなかったらデメリットはあるのか??
A. 画像や動画などファイルサイズが大きいコンテンツへのアクセスのたびにオリジンサーバーが処理するとサーバーの負荷が高くなりその結果サービスの安定した提供が実現できなくなる。
Cloud Frontを利用すればサーバの負荷の低減と安定したサービス提供が実現できるためサービス提供者・利用者のどちらにもメリットのあるシステムが構築できる。
オリジンサーバ(バックエンドサーバー)についてはELB、EC2、S3の静的ホスティングに加えAPI Gatewayやオンプレミスのサーバーなども指定可能。⇒ 既存のシステム構成を変更せずに導入ができる
URLのパスに応じて異なるオリジンサーバーを指定することで1つのドメインで複数のサービスを提供できる。
⇒ ドメイン名の統一や企業のwebガバナンス戦略にも役立つ。
※ webガバナンス:
企業のwebサイト運営と管理を統括する体制、仕組み。
拡張子やURLパスごとにキャッシュ期間を指定できる。
Lambda@Edge : CloudFrontとLambdaを組み合わせたサービス。
静的コンテンツに動的な条件を付けくわえることができる。
(できることは少ない)
レベル感としては配信されたコンテンツ、ヘッダーに手を加える程度
Amazon Route 53 :
ドメイン管理機能と権威DNS機能を持つサービス。
権威DNSについて
https://wa3.i-3-i.info/word12272.html
Aレコード、CNAMEレコードという言葉が出てきたが分からなかったので調べてみた
8種類のルーティングポリシーが存在し、要件に応じて適切なものを選択することで可用性や応答性の高いシステムを構築できる。
トラフィックフロー:
ルーティングポリシーを組み合わせることで複雑化するレコード間の設定をビジュアル的にわかりやすく扱うことのできるツール
利用イメージ
health check:
✅ エンドポイントのモニタリング
指定した一定の間隔でhealth checkを実行する。
自動リクエストをインターネット経由でアプリケーションやサーバーなどのリソースに送信してリソースが到達可能、使用可能、機能中であることを確認する。
✅ 他のhealth checkを監視するhealth check
最低限のリソースが正常であるかに重点を置く場合で有効。
利用できるウェブリソース数が閾値を下回る場合に通知を行うように設定できる。
✅ CloudWatchアラームをモニタリングするhealth check
AWS Global Accelerator :
ネットワークパフォーマンス最適化サービス。
インターネットトラフィックをAWSグローバルネットワークを通じて効率的にルーティングすることで通信のレイテンシーの改善や、静的IPアドレスによるエントリーポイントの提供、アプリケーションの保護などが可能。
CloudFrontとの違いとか載ってる記事
この記事が気に入ったらサポートをしてみませんか?