非凡な才能をください。

都心でサラリーマンやってます。書きます。

黒本(AWS WEB問題集)で学習する過程を記録する①(AWSソリューションアーキテクト-プロフェッショナルを1ヶ月で取得する)

 

これの続きです。

muessenwirwollen.hatenablog.com

  

黒本(WEB問題集)を実施したので振り返ります。

aws.koiwaclub.com

 

 

 

 

SAP02

Cloudsearch

マネージド型のウェブサイトやAP向けの検索サービス。一般的なウェブサイトやAP開発において、インデックスを付けるためのデータとトラフィック量の両方の要求を満たすための最適なボリュームを予測することが、検索機能の実装の課題だ。Cloudsearchは、容易な設定、コスト効率、スケーラビリティ、地理空間検索などの豊富な機能を備えており、この課題を解決する。
 
具体例
Elastic Beanstalkを使用して、複数のアベイラビリティーゾーンにウェブサイトをホストする。S3にスキャンファイルを保存する。ウェブサイトからスキャンファイルを利用するための、クエリ処理にCloudsearchを使用する。
 
 

SQS

フルマネージド型のメッセージングキューサービス。
 
具体例
以下のようなクラウドへの移行が考えられる。
 
クラウド移行前:オンプレサーバにデータ蓄積→RabbitMQ(OSSのメッセジングMW)→データ処理→データをテープに転送し、オフサイト保管
 
クラウド移行後:S3にデータ蓄積→SQSでジョブを溜める→AutoscalingでSQSのキュー深度に応じてスポットインスタンス(EC2ワーカー)を起動→データ処理→S3からGlacierにデータ転送
 
そもそもなぜメッセージングが必要となる?
フロントとバックエンドの間にメッセージングを入れることで、以下3点を実現する。
・非同期にすることで、クライアント側のリソースが少なくても、サーバ側に影響を与えないように、フロントで処理を完結させる。また非同期にすることで、業務処理を完全に分散することができるので効率的。(lambdaのトリガーにして、サーバレスにも取り組みやすい)
疎結合となることで、スケールしやすい
・タスクをバッファーできるので、スパイク的なアクセスに耐える構成を作り、耐障害性を高めることができる。
 
 
SQSに関する補足
①標準キューとFIFOキューがあり、後者は現時点ではLambdaやSNS連携をサポートしていない!
 
②キューにあるメッセージをサーバサイドで重複処理しないための可視性タイムアウト機能
 
 

カスタマーゲートウェイ

VPCは一つの仮装プライベートゲートウェイしか持てない。
・カスタマーゲートウェイと仮装プライベートゲートウェイを繋いでしまえば、可用性を高めるために2つのトンネルを構成し、VPN接続ができる。(仮装プライベートゲートウェイの定期メンテナンスがあるから必須)
・データセンター間を繋ぐ場合、それぞれ別のカスタマーゲートウェイを設置し、VPN接続すればよい。

 

 

SAP03

SQSの問題が間違っている

「順序性を担保するために、FIFOキューでLambdaがキックされるように設定する」が回答となっており、現在FIFOキューとLambda連携はサポートされていないため、誤っているように見える。あとでまとめてフィードバックするか。またこういうこともあるかと思うので、気になったところは自分で責任を持って進めることが必要だということを意識して取り組む。

 

Cloudformation

インフラの構成管理が容易にできる

AWS CloudFormation でインフラストラクチャをプロビジョニングすると、AWS CloudFormation テンプレートにプロビジョニングされたリソースやその設定が正確に記述されます。これらのテンプレートはテキストファイルであるため、テンプレート間の違いを追跡するだけでインフラストラクチャに対する変更を追跡できます。これは開発者がソースコードの変更を管理する方法に似ています。たとえば、バージョン管理システムをテンプレートに使用して、変更内容、変更者、変更日時を正確に把握できます。インフラストラクチャの変更を元に戻す必要がある場合はいつでも、テンプレートの以前のバージョンを使用できます。

リソース属性

作成、削除、変更、依存関係などのポリシーを設定できる。デフォルトではリソースが削除されてしまうため、DeletePolicyを設定することで、テスト実施後に環境が消えてしまって、テスト結果が見れないといったことを考慮して、段取りを組む必要がある。

 

docs.aws.amazon.com

EMR

EMRに限らず、各サービス使うときにはコスト最適化を意識したオプションの選択が必要。今回はコンピューティングの中でもEMRに関するインスタンスタイプのベストプラクティス。

アプリケーション向けのインスタンスの構成シナリオ

次の表は、通常さまざまなアプリケーションシナリオに適しているノードタイプ購入オプションと構成のクイックリファレンスです。各シナリオタイプの詳細情報を表示するには、リンクを選択します。

アプリケーションシナリオ マスターノード購入オプション コアノード購入オプション タスクノード購入オプション
長時間稼働クラスターおよびデータウェアハウス オンデマンド オンデマンドまたはインスタンスフリートの組み合わせ スポットまたはインスタンスフリートの組み合わせ
コスト主導の作業 スポット スポット スポット
データクリティカルな作業 オンデマンド オンデマンド スポットまたはインスタンスフリートの組み合わせ
アプリケーションのテスト スポット スポット スポット

Amazon EMR とは? - Amazon EMR