AWSSAA~重要サービス~
はじめに
インフラエンジニア初学者のぽれいんと申します。
※このブログでは自分が後々、見返すことができるようにまとめることを目的としていますが、もし需要があるようでしたら是非ともご覧ください。
<前回の記事>
<参考>
AWS IAM（ユーザーアクセスと暗号化キーの管理）| AWS
今回のやりたいこと
AWSソリューションアーキテクトアソシエイトの学習のためにAWSのサービスで最重要の次に重要なサービスを簡単にまとめたいと思います。需要があればご覧ください。
Route53
Route53はAWSのDNSサービス。WebコンソールやAPIから、簡単にドメイン情報やゾーン情報を設定・管理できる。Route53は単にドメインやDNS情報を管理するだけでなく、ネットワークトラフィックのルーティングや接続先のシステム状況に応じた接続先の変更など、オプション機能も持っている。
ドメイン管理
ドメインの取得からゾーン情報の設定までRoute53で一貫した管理が可能。ドメインの年間利用料は通常のAWSの利用料の請求に含まれるため、別途支払いの手続きも不要です。自動更新機能もありドメインの更新漏れといったリスクも回避できる。
ホストゾーンとレコード情報
ホストゾーンとはレコード情報の管理単位を表す。通常はドメイン名。たとえば、「example.com」のレコード情報を管理する場合のホストゾーンは「example.com」となる。レコード情報は、ドメイン名とIPアドレスを変更するための情報。
レコード情報には、Aレコード、MXレコード、CNAMEレコードといった種類があるが、Route53で特徴的なレコードとしてAliasレコードがある。Aliasレコードはレコード情報に登録する値として、CloudFrontやELB、S3などのAWSリソースFQDNを指定できる。CNAMEとの違いとしてZone Apexも登録できる。Zone Apexとは、最上位ドメインのこと。
トラフィックルーティング
要件や構成に応じて適切なトラフィックルーティングを指定することで可用性や応答性の高いシステムを構築することができる。
・シンプルルーティングポリシー
標準的な1対1のルーティング
・フェイルオーバールーティングポリシー
アクティブ/スタンバイ方式で、アクティブのシステムのヘルスチェックが失敗したときにスタンバイに切り替えることができる。S3と連携させることで、本番システム障害時にSorryサーバの静的コンテンツを表示させることができる。
・位置情報ルーティングポリシー
日本からのアクセスは日本語のコンテンツが配置されたWebサーバに接続するといった制御ができる。
・地理的近接性ルーティングポリシー
リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する際に使用。
・レイテンシールーティングポリシー
複数箇所にサーバーが分散されて配置されている場合に、遅延がもっとも少ないサーバにリクエストをルーティングする。特定サーバだけ高負荷になった場合にリクエストを分散できる。
・複数値回答ルーティングポリシー
１つのレコードに異なるIPアドレスを複数登録して、ランダムに変換されたIPアドレスに接続する。ヘルスチェックがNGになったIPアドレスは返却されないため、正常に稼働しているサーバにのみアクセスを分散できる。
・加重ルーティングポリシー
指定した比率で複数のリソースにトラフィックをルーティングする際に使用。拠点をまたがってリソースの異なるサーバが配置されている場合にリクエスト比率を調整することができる。
CloudWatch
CloudWatchは運用監視を支援するマネージドサービス。リリース後安定した運用をすることで利用者の満足度を上げていくことが非常に重要。
概要
CloudWatchは各AWSリソースの状態を定期的に取得する。この状態をメトリクスという。AWSがあらかじめ定義しているメトリクスを標準メトリクスという。標準メトリクスにメモリ使用率がないことはよく知られている。そのため、カスタムメトリクスと呼ばれる利用者が独自に作成したメトリクスを利用することで使用が可能。
CloudWatch logs
CloudWatch logsはログをモニタリングするサービス。使用するには独自のエージェントをインストールする必要がある。このエージェントを介して各EC2ログをCloudWatch logsに収集する。CloudWatchと同様に、このアラームをトリガーにしてアクションを定義することが可能。
CloudWatch Events
CloudWatch Eventsは独自のトリガーと何かしらの後続アクションとの組み合わせを定義するサービス。独自のトリガーをイベントソース、後続アクションをターゲットと呼ぶ。ターゲットに既存のAWSリソースに対するアクションを定義する。
CloudTrail
CloudTrailはAWSに関する操作ログを自動的に取得するサービス。CLIやSDKを用いたAPI操作によって、AWSリソースを操作したり、AWSリソースから情報を取得できる。CloudWatch logsと連携させることで不正な操作を早期に発見できる。
CloudFormation
AWS CloudFormationはAWSリソースを自動構築するためのサービス。構築されるAWSリソースはスタックと呼ばれる。スタックは、テンプレートと呼ばれる設計図に基づいて構築される。
利用の流れ
①CloudFormationテンプレートを作成
②テンプレートを適用
③CloudFormationスタックが作成される
④③に紐づく形でAWSリソースが自動構築される
CloudFront
Amazon CloudFrontはHTMLファイルやCSS、画像、動画といった静的コンテンツをキャッシュし、オリジンサーバのかわりに配信するCDNサービス。
CloudFrontのバックエンド
CloudFrontはCDNのため、元となるコンテンツを保持するバックエンドサーバ（オリジンサーバ）が必要。オリジンサーバとして、EC2、ELB、S3の静的ホスティングを利用することができる。また、オンプレミスのサーバを指定することが可能なため今のシステム構成を変更することなくCloudFrontを導入することでイベント等のアクセス増に備えることができる。
ディストリビューション
CloudFrontは配信するコンテンツの内容によって異なる２つのディストリビューションがある。ダウンロードディストリビューションはHTTPやHTTPSを使いHTMLやCSS、画像などのデータの配信に利用。ストリーミングディストリビューションはRTMPを使って動画のストリーミング配信をする際に利用。RTMPは時代の変化とともに2020年12月をもってサポートを終了。
キャッシュルール
頻繁にアップロードされる静的コンテンツはキャッシュ期間を短くし、あまり変更されないコンテンツ（画像・動画）はキャッシュ期間を長くするといった設定が必要。
ElastiCache
Amazon ElatiCacheは、AWSが提供するインメモリ型データベースサービス。高頻度で参照するデータや検索に時間がかかるデータセットをメモリ上に保持することでシステムのパフォーマンス向上に寄与する。
種類
ElastiCacheは2種類のエンジンをサポートしている。
Memcached
スタンダードで広く使われるエンジンでデータ処理パフォーマンスの向上に特化したキャッシュシステム。
・マルチスレッド
・非永続化
・単純なデータアーカイブ（String,Objects）
・メンテナンスが簡単
Radis
Memcachedより多くのデータが使えて、キャッシュ用途だけでなく、メッセージブローカーやキューを構成する要素としても利用される。
・シングルスレッド
・永続化
・多数のデータベースアーカイブ
・Atomic処理
・Pub/sub メッセージング
・リードレプリカ/フェイルオーバ
SQS
Amazon Simple Queue ServiceはAWSが提供するフルマネージドなメッセージキューイングサービス。キューイングサービスを介すことで疎結合になる。
SQSの機能
SQSの機能として、キューの管理とメッセージの管理の２つがある。キューとは、メッセージを管理するための入れ物のようなもので、作成すれば管理する必要がなく、エンドポイントと呼ばれるURLを介して利用する形になる。
キューの種類
キューはStandardキューとFIFOキューの2種類ある
Standardキュー
メッセージの配信順序を保証せず、同一のメッセージが2回配信される可能性がある。
FIFOキュー
メッセージの配信順序を保証する。秒あたりの処理件数はStandardキューに劣る。
ロングポーリングとショートポーリング
キューのメッセージ取得方法として、ロングポーリングとショートポーリングがある。両者の違いは、SQSのキュー側がリクエストを受けた際の処理にある。デフォルトのショートポーリングの場合はリクエストを受けるとメッセージの有無にかかわらず即レスを返す。これに対しロングポーリングはメッセージがない場合は設定されたタイムアウトのギリギリまでレスポンスを返さない。ショートポーリングはAPIの呼び出し回数も多くコストがかかる。複数のキューを単一スレッドで処理するような例外的ケース以外はロングポーリングを利用する。
可視性タイムアウト
メッセージは受信しただけでは削除されない。クライアント側から削除指示を受けたときに削除される。SQSには同じメッセージの受信を防止する機能として可視性タイムアウトがある。デフォルト設定値は30秒で最大、12時間まで延長可能。
デッドレターキュー
デッドレターキューは処理できないメッセージを別のキューに移動する機能。指定された回数処理が失敗したメッセージを通常のキューから除外してデッドレターキューに移動する。デッドレターキューを上手く使うと、アプリケーション側の例外処理を大幅に簡素化できる
メッセージキュー
キューに格納できるメッセージの最大サイズは256KB。文字列の情報に十分なサイズだが、画像情報などを扱うには足りない。SQSでは大きなサイズのデータはS3やDynamoDBに格納し、そこへのパスやキーといったポインター情報を受け渡すことで対応する。
SNS
Amazon Simple Notification Serviceはプッシュ型の通知サービス。マルチプロトコルのため、複数のプロトコルに簡単に配信できる。利用できるプロトコルはSMS、email、HTTP/HTTPS、SQSに加え、iOSやAndroidなどのモバイル端末へのプッシュ通知、Lambdaとの連携などが利用できる。メッセージをプロトコルごとに変換する部分はSNSが行うので、通知する人（Publisher）はプロトコルの違いを意識することなく配信できる。SNSはSQSやCloudWatchなどと組み合わせてシステム間の連携や外部への通知などに利用する。
SNSの利用
SNSはトピックという単位で情報を管理する。システムの管理者は、メッセージを管理する単位でトピックを作成する。トピックの利用者には通知する人（Publisher）と通知される人（Subscriber）がいる。Subscriberは利用するトピックと受け取るプロトコルを登録する。これを購読という。
以上！！！！！
