136-AWS SAP AWS 「理論・実践・一問道場」Amazon DocumentDB

type

status

date

slug

summary

理論

クロスアカウントVPCピアリングを CloudFormation でやってみた | DevelopersIO

他の Amazon VPC と通信する方法としていつかの方法がありますが、その1つにVPC ピアリングがあります。（詳しくは以下をご参照ください）

https://dev.classmethod.jp/articles/vpc-peering-cfn/

DocumentDBとMongoDBの違い

DocumentDBは、AWSが提供する完全マネージド型のドキュメントデータベースで、MongoDB互換のAPIを提供します。スキーマレスでJSON形式のデータを格納し、パフォーマンス、スケーラビリティ、可用性に優れた環境を提供します。自動的なストレージ拡張や高可用性、データリカバリ機能が特徴です。また、Amazon DocumentDBは、MongoDB 3.6および4.0との互換性を持ち、アプリケーションの移行を容易にします。

一方、MongoDBはNoSQLドキュメント指向データベースで、高速なデータ処理やシャーディング、レプリカセットによる負荷分散、冗長化が可能です。JSONに似た形式でデータを扱い、外部システムとの連携が簡単です。

主な違い

API互換性：DocumentDBはMongoDBと互換性があり、AWSのマネージドサービスで運用されます。MongoDBは一般的に自前で管理されます。

ストレージエンジン：DocumentDBは独自のエンジンを採用し、MongoDBはWiredTigerエンジンを使用します。

バックアップ：DocumentDBはRDSと同様に簡単にバックアップが可能で、ポイントインタイムリカバリをサポートします。MongoDBは専用ツールや手動によるバックアップが必要です。

まとめ

両者の主な違いはストレージエンジンとクラスタアーキテクチャであり、運用面で異なる影響を及ぼします。互換性を活かして、それぞれの特性に最適な活用方法を選ぶことが重要です。

オンデマンドキャパシティモードとは

オンデマンドキャパシティモードは、Amazon Web Services (AWS) のデータベースサービス、特に Amazon DocumentDB や Amazon DynamoDB などのサービスで利用できるキャパシティモードの一つです。このモードでは、リソースのスケーリングや管理をAWSが自動で行い、アプリケーションが要求する容量に合わせて処理能力を自動的に調整します。

具体的には、オンデマンドキャパシティモードでは、事前にプロビジョニングを行う必要がなく、リクエストに基づいて自動的にスケールイン・スケールアウトします。これにより、負荷の変動が激しい場合でも柔軟に対応でき、容量の過不足を気にすることなく運用することができます。特にトラフィックが予測できない、または急激に変動するアプリケーションに適しています。

主な特徴:

スケーラビリティ: システムがトラフィックの増減に応じて自動的にスケーリングするため、事前に容量を設定する必要がない。

コスト効率: 実際に使った分だけ支払うモデルなので、無駄なコストを削減できる。

簡単な管理: 管理者は容量のプロビジョニングや調整を行う必要がなく、AWSがリソースを自動で最適化。

他のキャパシティモード:

プロビジョンドキャパシティモード: 使用するリソース量を事前に設定するモード。安定したトラフィックが見込まれる場合に最適で、リソースのオーバープロビジョニングを防ぐために調整が必要。

サーバーレスモード（DynamoDBの場合）: ユーザーがリソースを管理することなく、アプリケーションがリクエストに応じて必要な容量を自動的にスケーリングできるモード。

実践

略

一問道場

質問 #136

トピック 1

ある会社が、賃貸希望者や購入希望者向けに不動産情報を提供するオンプレミスのウェブサイトアプリケーションを運用しています。このウェブサイトは、JavaバックエンドとNoSQLのMongoDBデータベースを使用して、購読者データを保存しています。

会社は、このアプリケーション全体をAWSに移行する必要があり、同様の構成を維持したいと考えています。アプリケーションは高可用性でデプロイする必要があり、アプリケーションに変更を加えることはできません。

どのソリューションがこれらの要件を満たしますか？

A. 購読者データのデータベースとしてAmazon Aurora DBクラスターを使用し、Javaバックエンドアプリケーション用に、複数のアベイラビリティゾーンにまたがるAuto ScalingグループでAmazon EC2インスタンスをデプロイします。

B. 購読者データのデータベースとしてAmazon EC2インスタンス上のMongoDBを使用し、Javaバックエンドアプリケーション用に、単一のアベイラビリティゾーン内のAuto ScalingグループでEC2インスタンスをデプロイします。

C. 購読者データのデータベースとして、適切にサイズ設定されたインスタンスで複数のアベイラビリティゾーンに展開されたAmazon DocumentDB（MongoDB互換）を使用し、Javaバックエンドアプリケーション用に、複数のアベイラビリティゾーンにまたがるAuto ScalingグループでAmazon EC2インスタンスをデプロイします。

D. 購読者データのデータベースとして、オンデマンドキャパシティモードで複数のアベイラビリティゾーンに展開されたAmazon DocumentDB（MongoDB互換）を使用し、Javaバックエンドアプリケーション用に、複数のアベイラビリティゾーンにまたがるAuto ScalingグループでAmazon EC2インスタンスをデプロイします。

解説

この問題の解説を行います。

問題概要

会社が提供している不動産情報を扱うウェブサイトアプリケーションが、JavaバックエンドとNoSQLのMongoDBデータベースを使用しています。現在、アプリケーションはオンプレミス環境で運用されていますが、AWSに移行する必要があります。移行後は、高可用性を確保する必要があり、アプリケーションに変更を加えることはできません。

選択肢の検討

A. Amazon Aurora DBクラスターを使用して、JavaバックエンドアプリケーションのためにAuto Scalingグループを複数のアベイラビリティゾーンに展開する。

問題点: Amazon Auroraはリレーショナルデータベースであり、MongoDBのようなNoSQLデータベースとは異なります。問題の要件にはMongoDB互換性が必要ですが、AuroraはNoSQLに対応していません。そのため、この選択肢は適していません。

B. MongoDBをAmazon EC2インスタンスで使用し、JavaバックエンドアプリケーションのためにAuto Scalingグループを単一のアベイラビリティゾーンで展開する。

問題点: MongoDBをEC2インスタンスで使用することは可能ですが、アベイラビリティゾーンが1つだけの場合、高可用性を確保することができません。この問題では「高可用性」が求められているため、この選択肢も適していません。

C. Amazon DocumentDB（MongoDB互換）を使用し、複数のアベイラビリティゾーンにインスタンスを配置して、JavaバックエンドアプリケーションのためにAuto Scalingグループを展開する。

正解: Amazon DocumentDBはMongoDBと互換性があり、高可用性を提供するマネージドサービスです。複数のアベイラビリティゾーンにインスタンスを配置することによって、高可用性を確保できます。また、AWSが自動的にスケーリングを管理し、バックエンドアプリケーションを高可用性で運用できるため、この選択肢は要件に合致します。

D. Amazon DocumentDB（MongoDB互換）をオンデマンドキャパシティモードで使用し、複数のアベイラビリティゾーンにインスタンスを配置して、JavaバックエンドアプリケーションのためにAuto Scalingグループを展開する。

問題点: オンデマンドキャパシティモードは、通常、トラフィックの予測が難しい場合や、使用量が不規則な場合に有効ですが、この場合のアプリケーションは明確に定義されたワークロードを持っている可能性が高いです。また、オンデマンドキャパシティモードは負荷が急激に増加した際にスケールできる一方で、コスト管理が難しくなることがあります。したがって、この選択肢はやや過剰なリソース管理のアプローチかもしれません。

結論

C が最適な選択肢です。Amazon DocumentDBはMongoDB互換であり、複数のアベイラビリティゾーンに展開することで高可用性を確保できます。