Amazon Web Services ブログ
Amazon S3 におけるマルチテナント SaaS データのパーティション化と分離
この記事は、Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3 を翻訳したものです。
多くの software-as-a-service (SaaS)アプリケーションはマルチテナントデータを Amazon Simple Storage Service(Amazon S3) に保存しています。Amazon S3 にマルチテナントデータを配置するには、バケットとキーにテナントデータをどのように分散させるかを考える必要があります。それは、SaaS ソリューションのセキュリティ、管理性、パフォーマンスを損なうことなく行う必要があります。
この記事では、Amazon S3 でテナントデータをパーティション化する際に適用できるさまざまな戦略を説明します。これらの戦略を自社のソリューションに適用する際に影響を与える可能性のある考慮事項を明示し、パーティション戦略がテナント分離と S3 オブジェクトへのアクセス制限にどのような影響を与えるかを見ていきます。
Amazon S3 データパーティション化
マルチテナントデータを表現するためのさまざまなアーキテクチャパターンを検討する際、そのデータをどう編成するか決める必要があります。このようなマルチテナントストレージメカニズムとパターンを通常、データのパーティション化と呼びます。
各 Amazon Web Services (AWS) ストレージ技術は通常、データパーティショニングモデルの独自のコレクションを持っています。これはソリューションのさまざまなニーズをサポートするためにテナントオブジェクトをどのように編成できるかを検討する際、 Amazon S3 においても言えることです。
どのパターンを選択するかは、いくつかの要因に影響を受けることに注意することが重要です。推定総テナント数、テナント環境の分離モデル、アプリケーションのアクセスパターンは、選択するオプションに影響を与える可能性のある考慮事項の 1 つです。
以下のセクションでは、一般的なマルチテナント S3 戦略を見ていき、これらの戦略がどんなケースでどのように適用されるかに焦点を当てます。
テナント専用バケットモデル (Bucket-Per-Tenant)
テナントデータを Amazon S3 でパーティション化する最も単純なアプローチは、テナント毎に個別のバケットを割り当てることです。以下の図は、このモデルの例を示しています。
このアプローチでは、各テナントにデータを保持するバケットが割り当てられます。このバケットには、テナントと一意に結びつく名前が付けられます。
このモデルは、少数のテナント (数十または数百) を扱う場合にうまく機能します。しかし、はるかに多くのテナントをサポートする必要のある環境には適していません。Amazon S3 には、AWS アカウント毎にデフォルトで最大 100 バケットの制限があります (ハード制限は 1000) があります。
もう 1 つの考慮事項は、バケット名です。各 S3 バケット名はすべての AWS アカウント全体でグローバルに一意である必要があるため、テナント毎のバケットモデルではこの要件をサポートする命名規則が必要になります。 バケット名は公開されているため、一般にテナント固有の情報を含む名前は避けるべきです。
最後に、S3 バケット数の制限は、この SaaS アプリケーション固有のものではありません。他の環境 (本番、ステージング、開発) や専用のバケットを必要とする AWS サービスがクォータの一部を利用している可能性があります。
全体として、テナント毎のバケットモデルはシンプルですが、 SaaS 環境のスケールと俊敏性に影響を与える可能性のあることは明白です。
テナント毎のオブジェクトキープレフィックス モデル
SaaS プロバイダーはテナント専用バケットモデルの制限を克服し、より大規模な展開を実現するために、キーのプレフィックスを使用してオブジェクトをテナントと関連付ける場合があります。このアプローチによりデータパーティション構造や編成を損なうことなく、はるかに大規模なテナントコレクションに拡張できます。
ここでは、 2 つのテナントが 1 つのバケットを共有しています。各テナントには、そのテナントに属するオブジェクトを識別する一意のプレフィックスがあります。幸いなことに、バケットに格納できるオブジェクト数やプレフィックス数には制限がないです。
表面化する可能性のある課題の 1 つは、S3 キーに対する操作がテナント全体で均等に分散している可能性が低いことです。パーティション分割されたプレフィックス毎に、ソリューションは 1 秒間に数千のトランザクションを実現できます。個々のテナントのプレフィックスをシャーディングすることで、負荷をより分散させることができます。
データベースでマッピングしたテナントオブジェクト
場合によってはアプリケーションのオブジェクトアクセスパターンが S3 オブジェクトのパーティション分割方法の選択に影響することがあります。アプリケーション固有の基準 (たとえば、project-a に属する tenant-1 オブジェクトをすべて検索する) を満たすテナントのオブジェクトを検索したいシナリオを想像してみましょう。
ここでのアイデアは、検索可能な要素をデータベースに移動し、そのデータベースを検索して S3 オブジェクトへの参照を見つけ出す、ということです。以下の図は、このユースケースの例を示しています。
この例では、S3 オブジェクトのリクエストを処理するオブジェクトアクセスサービスを図に導入しました。このサービスは、アプリケーションで管理されているいくつかの基準に基づいて S3 オブジェクトをリクエストする機能をサポートするアプリケーションのマイクロサービスになります。
テナントはパラメーターを指定してリクエストを送信し、サービスは識別されたテナントとクエリに必要なパラメーター (ProjectID など) を含むデータベースにクエリを実行します。これらのパラメーターは、データベースをクエリして特定のテナントの S3 オブジェクトを参照するために使用されます。
データベースを使用して S3 オブジェクトへのアクセスを管理しているため、この例ではすべてのテナントの S3 オブジェクトをフラットな階層に混在して格納しています。これらのオブジェクトを常にデータベースから見ることができるのであれば、データベース内のテナント ID の列は、テナント ID に基づいて分離が適用されるパーティショニングモデルを表している可能性があります。これにより、S3 オブジェクトを、このマッピングデータベーステーブルを介してテナントに接続されたオブジェクトのグローバルプールとして保存できます。フラットな構造では、リクエストスロットリングを避けるためにプレフィックスがランダムな固有のオブジェクトキーが必要です。
さらに、このアプローチは、テナントオブジェクトをプレフィックスで分割した、テナント毎のプレフィックスと組み合わせたハイブリッドモデルでもかまいません。その他に S3 オブジェクトタグを使用して、格納されている各オブジェクトにテナントのメタデータを追加する方法があります。Amazon S3 オブジェクトのタグ付けには追加料金がかかります。
顧客による直接アクセスや AWS サービス統合など、オブジェクトアクセスサービスの外部に他のアクセスパターンがある場合は、オブジェクトにキープレフィックスまたはタグを追加するとよいでしょう。
テナント分離
テナントの分離は、すべての SaaS プロバイダーが対処しなければならない基本的なトピックの 1 つです。これは、あるテナントが別のテナントのリソースにアクセスできないようにするアーキテクチャの仕組みです。ここで障害が発生すると、SaaS ビジネスにとって重大で回復不能な事態になる可能性があります。
S3 データパーティション化のモデルを選択する際には、特定のパーティション化モデルがソリューションのテナント分離フットプリントにどのように影響するかも考慮する必要があります。テナント単位およびテナント単位のプレフィックス戦略では、テナント固有の AWS Identity and Access Management (IAM) ポリシーを定義できます。これにより、サービス固有のリソース、アクション、条件コンテキストキーを使用して、テナント間でリソースにアクセスできないようにすることができます。
さまざまなパーティション化モデルに使用される IAM ポリシーは、SaaS 環境のニーズとポリシーサイズ制限に基づいて、静的に作成することも、動的に生成することもできます。この戦略の詳細については、「動的に生成された IAM ポリシーによる SaaS テナントの分離」をご覧ください。
エンドポイントベースのパーティション化と分離
Amazon S3 アクセスポイントは、S3 オブジェクトへのアクセスを可能にする名前付きのネットワークエンドポイントです。これにより、S3 データを一連のバケットやキーと見なす必要がなくなります。代わりに、アクセスポイントを使用して各テナントのデータへのアクセスを制御することに焦点が移ります。デフォルトでは、1 つのアカウントに設定できるアクセスポイントのクォータは 1,000 個です。
この方法では、特定のテナントに関連付けられているオブジェクトへのアクセスを管理できるポリシーを使用して、個々のテナントのエンドポイントを定義できます。アクセスポイントは、S3 バケット名、オブジェクトキープレフィックス、またはオブジェクトタグ制限をサポートする静的に設定された IAM ポリシーを使用します。
これにより、テナントの分離を維持しながら、他の AWS サービスまたはアカウントから S3 オブジェクトにアクセスできます。アクセスポイントは AWS のサービスや機能の一部で動作しますが、すべてではありません。また、SaaS のお客様が自分の AWS アカウントから S3 オブジェクトに直接アクセスできるようにすることもできます。
暗号化キーによるテナントオブジェクトの保護
SaaS ソリューションの S3 パーティション化モデルは、追加のセキュリティ上の考慮事項の影響を受ける可能性があます。環境によっては、組織のコンプライアンスやデータ機密性のニーズにより、暗号化によるオブジェクトの保護をさらに強化する必要があります。
ここでは、各テナントにデータを保護するキーをどのように提供できるかに重点をおきます。このようなシナリオでは、Amazon S3 を AWS Key Management Service (AWS KMS) と組み合わせて使用すると、S3 オブジェクトをサーバー側で暗号化できます。
採用した S3 パーティション化モデルは、キーの適用方法に影響します。たとえば、テナント単位のバケットモデルでは、バケット毎に固有の暗号化キーを割り当てることができます。
テナント毎のプレフィックスモデルでも、エンベロープ暗号化を使用してルート暗号化キーを共有し、各オブジェクトを個別に暗号化できます。エンベロープ暗号化とは、プレーンテキストデータをデータキーで暗号化し、そのデータキーをルートキーで暗号化することです。
アプリケーションコードがオブジェクトの書き込みリクエストを処理する場合、オブジェクトごとに暗号化に使用する AWS KMS キーを指定できます。AWS アカウントの各リージョンで、最大 10,000 個のカスタマー管理キーを使用できます。また、オプションでオブジェクト毎に追加の暗号化コンテキストを指定し、認証化された暗号化をサポートすることもできます。
AWS Key Management Service によるサーバー側の暗号化 (SSE-KMS) を使用すると、Amazon S3 バケットキーにより AWS KMS リクエストのコストを最大 99% 削減できます。この S3 バケットキーは S3 内で一定期間使用され、同じ AWS KMS キーで暗号化されたオブジェクトの S3 バケットキーのみが共有されます。これにより、KMS API のリクエスト数の制限を下回ることができます。
暗号化と IAM ポリシーは、全体的なセキュリティとテナント分離モデルの一部として組み合わせることができます。
テナントの活動と利用量
SaaS ソリューションは多くの場合、製品のコストが顧客の利用プロファイルに基づいて決定される従量課金制モデルで販売されます。テナントレベルでコスト情報を追跡することで、メータリングや価格設定を利用量ベースで決定できます。
テナント単位のバケットモデルでは、コスト配分タグを使用して個別の S3 バケットにラベルを付けることで、テナントのストレージコストを追跡できます。
テナント毎のプレフィックスアプローチでは、Amazon S3 インベントリを使用して S3 の利用量を追跡できます。これには、ソースバケット内のオブジェクトのリストと各オブジェクトのメタデータが含まれます。メタデータフィールドにはキー名とサイズが含まれます。ただし、インベントリリストにはオブジェクトタグは含まれていません。S3 バケットまたは共有プレフィックスのインベントリは、日単位または週単位で生成できます。
インベントリ完了時の Amazon S3 イベント通知を設定できます。Amazon S3 インベントリには追加料金がかかります。
Amazon Athena を使用すると、S3 インベントリをすばやく分析してクエリを実行することもできます。Athena では実行したクエリに対してのみ支払いが発生し、各クエリでスキャンされたデータ量に基づいて課金されます。
サーバーアクセスログは、S3 バケットに対して行われたリクエストの詳細な記録を提供します。これらのログを使用してテナントの API リクエストとデータ転送コストの両方に関する S3 請求額を分析できます。これは、Amazon Athena を使用してサーバーアクセスログの分析とクエリを行うことができる一例です。ログレコードフィールドには、時間、バケット、キー、送信バイト数、オブジェクトサイズが含まれますが、オブジェクトタグは含まれません。
これらのログはベストエフォート方式で配信されることに注意してください。ログレコードが失われることはほとんどないですが、リクエストが実際に処理されてから特定のリクエストのログレコードの配信されるまで時間がかかることがあります。
ライフサイクル設定ルールの利用
Amazon S3 では、S3 オブジェクトのライフサイクルを定義することもできます。SaaS 環境ではテナント毎に (ティアやその他のアプリケーションに対する要件に基づいて) 異なるライフサイクルポリシーを提供することもできます。
これらの S3 ライフサイクル管理ルールを使用して、オブジェクトを別のストレージモデルに移行するタイミングがいつ期限切れになるか判断できます。たとえば、プレミアム階層のテナントには、基本階層のテナントとは異なる移行ルールが適用される場合があります。
ライフサイクルルールは、ライフサイクルルールで指定した <Filter> 要素に基づいて、バケット内のすべてまたは一部のオブジェクトに適用できます。キープレフィックス、オブジェクトタグ、またはその両方の組み合わせでオブジェクトをフィルタリングできます。S3 ライフサイクル設定には最大 1,000 個のルールを設定できますが、この制限は調整できません。
S3 バケットのその他の設定
Amazon S3 のセキュリティとアクセス管理に関する AWS re: Invent 2021 セッションは、マルチテナントの SaaS アプリケーションで使用されているもの含め、すべての Amazon S3 バケットにおけるコストとセキュリティ管理に有益です。
- Amazon S3 Intelligent-Tiering ストレージクラスは、アクセスパターンが変化すると、運用上のオーバーヘッドやパフォーマンスへの影響なしに、データを最も費用対効果の高いアクセス階層に自動的に移動することで、ストレージコストを最適化するように設計されています。
- S3 バケットのアクセスコントロールリスト (ACL) を無効にすることをお勧めします。
- アカウント管理者とバケット所有者は、S3 Block Public Access を使用することで、リソースの作成方法に関係なく S3 リソースへのパブリックアクセス制限を簡単に一元管理できます。
まとめ
Amazon S3 にマルチテナントデータを正しく保存することは、多くの SaaS アプリケーションにとって重要です。この記事では、データパーティション化の複数のオプションとその主な考慮事項について説明しました。アクセスポリシーや暗号化など、テナント分離をサポートする戦略を言及しました。
テナントのアクティビティとコストトラッキング、オブジェクトのライフサイクル管理、その他のバケットセキュリティ設定に関する関連情報も含まれています。
AWS SaaS Factory について
AWS SaaS Factory は、SaaS 導入のどの段階の企業でも支援します。新製品の構築、既存のアプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、どのようなご要望にもお応えします。AWS SaaS Factory Insights Hub では、技術的、ビジネス的なコンテンツやベストプラクティスをご覧いただけます。
また、SaaS 開発者の方は、エンゲージメントモデルや AWS SaaS Factory チームとの連携について、アカウント担当者にお問い合わせください。
こちらにご登録いただくと、最新の SaaS on AWS ニュース、リソース、イベントの情報を入手できます。