Amazon Web Services ブログ

Category: Technical How-to

Amazon EFS を使用して WordPress のパフォーマンスを最適化する

多くの組織は、単一ノードインストールを使用して WordPress のようなコンテンツ管理システム (CMS) を使用していますが、マルチノードインストールがパフォーマンスと可用性の面でメリットを提供するベストプラクティスであることから、これを使用することで恩恵を受けることができます。AWS Well-Architected フレームワークの信頼性の柱では、次の設計原則を推奨しています。すなわち、「水平方向にスケールしてシステム全体の可用性を高める: 1 つの大規模なリソースを複数の小規模なリソースに置き換えることで、単一の障害がシステム全体に与える影響を軽減します。リクエストを複数の小規模なリソースに分散させることで、共通の障害点を共有しないようにします」というものです。 このブログ投稿では、Amazon Elastic File System (Amazon EFS) を可用性の高い WordPress デプロイの共有コンテンツストアとして使用する方法について説明し、サイトのパフォーマンスを改善するための最適化のヒントを紹介します。 マルチノードの WordPress サイトを実行する 1 つのアプローチは、ファイルを 1 か所に保存し、ブートストラッププロセス中にこのデータをダウンロードすることです。これでも機能しますが、このオプションを使用すると、ウェブサイトの進化に合わせてコンテンツを常に同期することが難しくなります。Amazon EFS のような共有ファイルシステムを使用すると、複数のノードが同時に WordPress ファイルにアクセスできます。これにより、水平スケーリングとウェブサイトの更新のプロセスを大幅に簡略化できます。 ページをロードする時間を理解する Amazon EFS は、AWS クラウドサービスおよびオンプレミスリソースで使用するための、シンプルでスケーラブルで伸縮自在な完全マネージド型の NFS ファイルシステムを提供します。アプリケーションの運用を妨げることなく、オンデマンドでペタバイト単位にまで拡張できるように構築されており、ファイルを追加および削除すると自動的に拡大および縮小するため、成長に対応するためにキャパシティーをプロビジョニングしたり管理したりする必要はありません。Amazon EFS はリージョナルサービスであり、複数のアベイラビリティーゾーン内およびこれらにまたがってデータを保存し、高可用性と耐久性を実現しています。 ネットワーク化されたファイルシステムについては、クライアントとサーバー間のネットワーク通信に関連するオーバーヘッドがあります。シングルスレッドアプリケーションから小さなファイルを操作する場合、このオーバーヘッドも併せて大きくなります。多くの場合、マルチスレッド I/O およびより大きなファイルの I/O はパイプライン処理できるため、ネットワークのレイテンシーをより多くの操作で償却できます。 例えば、PHP ウェブサイトがホームページを生成するには、100 個の小さなファイルにアクセスする必要があるとします。これは、PHP ファイル、インクルード、モジュールなどです。PHP パーサーにページをロードするときに小さな 1 桁のミリ秒の低レイテンシーを導入すると、ユーザーがウェブサイトにアクセスするときに数百ミリ秒のさらなる遅延が発生します (100 ファイル X 数ミリ秒の遅延)。ウェブページのロードに対するユーザーの許容度はそれほど高くないため、これは重要です。 この図は、ページをロードするために実行する必要があるさまざまな手順を示しています。各ステップで追加のレイテンシーが発生します。私たちは、WordPress […]

Read More

AWS上でどのようにゼロトラストアーキテクチャを考えていくか

厳しい規制への対応やリスク回避を考慮事項として擁するお客様は、レガシーアプリケーションのリファクタリングや新しいアプリケーションのデプロイに際し、ゼロトラストアーキテクチャに関心を向けることがあります。このブログでは、お客様がお客様のアプリケーションを評価し、ゼロトラストの原則とAmazon Web Services (AWS)を利用して安全でスケーラブルなアーキテクチャを構築するための手助けを行います。 ゼロトラストとは? ゼロトラストセキュリティとは、アプリケーションのコンポーネントやマイクロサービスが互いに分離しており、どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼していないというモデルです。これは、あらゆるソースからの入力を潜在的に悪意のあるものとみなすように設計されたセキュリティの考え方です。基礎となる内部ネットワーク・ファブリックを信頼しないことから始まり、さらにすべてのマイクロサービスにおける入力と出力の評価におよびます。加えて、個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計することも含まれます。 (訳者注:ゼロトラストは特定の製品やソリューションを指すものではなく多層的なセキュリティ手法を踏まえた概念として、現在アメリカ国立技術標準研究所(NIST)においても、SP800-207(本blog執筆時点においてはドラフト)として定義化が進められています。) 伝統的なネットワークセキュリティの設計は、セキュリティの境界に依拠します。境界内のすべてのものは信頼され、境界外のものは信頼できないものとみなされます。ゼロトラストネットワークは、ビジネスデータや機密リソースへの意図しないアクセスのリスクを低減するために、リアルタイムですべてのアクションとリソースを評価します。 ゼロトラストの原則を用いたAWS上での設計 ゼロトラストアーキテクチャをよりよく理解するために、脅威モデリングにより、従来のアーキテクチャやクラウドネイティブアーキテクチャとを比較してみましょう。脅威モデリングは、ユーザーはすべての潜在的な攻撃の可能性を評価してリスクを定義し、管理策を決定するための試みです。脅威モデルの一つであるSTRIDEでは、以下のようなカテゴリの脅威を特定しています。 ユーザーIDのなりすまし(Spoofing) データの改ざん(Tempering) ソースの否認(Repudiation) 情報漏洩(Information Disclosure) サービスの拒否(Denial of Service) 特権の昇格(Elevation of Privilege) AWSのベストプラクティスアーキテクチャ AWSでは、AWS上でWell-Architectedなアプリケーションを設計するための基礎となるツールを提供しています。AWS Well-Architected Frameworkは、AWSのベストプラクティスとワークロードを比較し、安定的かつ効率的なシステムを構築するためのガイダンスを得るための戦略を紹介しています。Well-Architected Frameworkには、セキュリティを含む5つの明確な柱が含まれています。このフレームワークを基に、ゼロトラストをAWSアーキテクチャに適用した例としてWebアプリケーションを考えてみましょう。 図1: Webサイトホスティングの例 表現されているアーキテクチャは、セキュリティを考慮したWell architectedの一例です。システムは、以下のサービスを活用して一般的な攻撃ベクターから保護されています。 Elastic Load Balancing (ELB)/Application Load Balancer (ALB)による負荷分散により、複数のアベイラビリティゾーンとAmazon Elastic Compute Cloud (Amazon EC2) Auto Scalingグループに負荷を分散し、サービスの冗長化と疎結合を実現します。 AWSのSecurity Groupを利用した仮想ファイアウォールでは、インスタンスにセキュリティを移動させ、Webサーバとアプリケーションサーバの両方にステートフルなホストレベルのファイアウォールを提供します。 Amazon Route 53を利用したDNS(Domain Name System)はDNSサービスを提供し、ドメイン管理を簡素化します。 Amazon CloudFrontによるエッジキャッシングにより、顧客へのレイテンシが減少します。  AWS Web […]

Read More

S3 バケット間で既存のオブジェクトをレプリケートする

 お客様は、そのビジネス要件またはエンタープライズポリシー上、既存の Amazon S3 オブジェクトの追加コピーを求められることがよくあります。Amazon S3 レプリケーションは、新しくアップロードされたオブジェクトを S3 バケット間でレプリケートするために広く使われていますが、S3 バケット間で既存のオブジェクトを多数レプリケートする最も簡単な方法をまだご存知ではないお客様が数多くいらっしゃいます。この記事では、Amazon S3 レプリケーションを使用して既存のオブジェクトのクロスリージョンレプリケーションをトリガーする方法を説明します。 Amazon S3 レプリケーションは、オブジェクトをある Amazon S3 バケットから別のバケットにコピーするための、低コストで柔軟なマネージド型ソリューションです。Amazon S3 レプリケーションでは、Amazon S3 Cross-Region Replication (CRR) を使って、異なる AWS リージョンをまたいで S3 オブジェクトを自動的にレプリケートするルールを設定できます。または、Amazon S3 Same-Region Replication (SRR) を使用して、同じ AWS リージョン内のバケット間でオブジェクトをレプリケートするルールを設定できます。 お客様は、AWS サポートに連絡してこの機能をソースバケットに追加することにより、同じ AWS リージョン内または異なる AWS リージョン間の別のバケットに既存のオブジェクトをコピーできます。ソースバケットで既存のオブジェクトのレプリケーションのサポートを有効にすると、お客様は、新しくアップロードされたオブジェクトに加えて、既存のすべてのオブジェクトに対して S3 レプリケーションを使用できるようになります。レプリケーションプロセスが完了すると、お客様はすべてのオブジェクトが含まれる 2 つのバケットを持つことができ、新しくアップロードされたオブジェクトは宛先バケットにレプリケートされます。 既存のオブジェクトのレプリケーションは、既存の S3 レプリケーション機能を拡張したものであり、同じ機能がすべて含まれます。これには、メタデータ (オブジェクトの作成日時など) を保持しながらオブジェクトをレプリケートしたり、オブジェクトを異なるストレージクラスにレプリケートしたり、異なる所有権でオブジェクトのコピーを保持したりする機能が含まれます。Amazon S3 Replication Time Control […]

Read More

Amazon S3 暗号化を S3 マネージドから AWS KMS に変更する

 Amazon Simple Storage Service (Amazon S3) を使用するお客様は、サーバー側のオブジェクト暗号化 (SSE) に S3 マネージド暗号化キー (SSE-S3) を利用することがよくあります。多くのお客様の場合、SSE-S3 を使用することにより、データを保護するためのセキュリティ要件を満たしています。一方で、一部のお客様の場合、最初は SSE-S3 が要件を満たしていたはずが、時間の経過とともに要件が変更された可能性があります。たとえば、顧客が別の標準セットに対する準拠を必要とする新しいビジネスを拡張している場合があります。別の例として、分析を使用するお客様の多くは、機密データ以外を使用して概念実証を実行することから始めます。分析プラットフォームから価値を引き出すにつれて、さまざまなデータソースからさらに多くのデータを追加し、このデータ集約によって分類が変更されることがよくあります。暗号化キーにアクセスできるユーザーをより詳細に制御できるようにすることで、暗号化キーを処理するための追加制御を実装しなければならない場合があります。また、ログ記録と監査を分離したり、ストレージと暗号化を別々に認証するための PCI-DSS コンプライアンス要件をサポートしたりすることもできます。AWS マネージドキーとカスタマーマネージドキーの違いについては、このブログ記事をご覧ください。 より強力なセキュリティとコンプライアンスの要件を満たすために、一部のお客様は、暗号化モデルを SSE-S3 から SSE-KMS に変更したいと思う場合があります。SSE-KMS は、暗号化に AWS Key Management Service (AWS KMS) を使用します。そうすることで、許容が大きすぎるポリシーからの保護など、いくつかの追加利点を提供できます。たとえば、個々のユーザーやロールではなく、過度に広いデータへのアクセスを許可するバケットポリシーを追加します。KMS キーを使用して暗号化を実装することにより、リソースにアクセスする者は、Amazon S3 ポリシーアクセスと、データを復号化するための KMS キーへのアクセスを必要とします。カスタマーマネージドキーで AWS KMS を使用することを選択したお客様には、追加のコンプライアンス要件をサポートできる次の利点もご利用いただけます。 キーの所有権を維持してアクセスを取り消し、データへのアクセスを不可能にします。 独自のコンプライアンス要件に合わせて、AWS KMS コンソールから監査可能なカスタマーマネージド CMK を作成、ローテーション、無効化することができます。 AWS KMS のセキュリティ管理は、暗号化関連のコンプライアンス要件を満たすのに役立ちます。 この記事では、4 つのことを説明します。 暗号化に KMS キーを使用するよう、バケットにデフォルトの暗号化を設定する方法。 […]

Read More

Amazon S3 で削除マーカーレプリケーションを管理する

お客様は、同じ AWS リージョン内または別の AWS リージョン内にデータのコピーを作成して、コンプライアンス、レイテンシーの短縮、またはアカウント間でのデータの共有を実現するために、Amazon S3 レプリケーションを使用します。データが絶えず変化している環境では、多くのお客様が、削除されるオブジェクトに対するレプリケーションのニーズが異なります。このブログでは、V1 と V2 の 2 つの設定のレプリケーション動作、および特定のコンプライアンスとガバナンスのニーズを満たす設定を選択する方法について説明します。 S3 レプリケーションの概要 S3 レプリケーションは、あらゆる Amazon S3 ストレージクラスに、低コストで伸縮自在なフルマネージド型のエンタープライズ対応レプリケーション機能を提供し、誤った削除から保護するとともに、異なるリージョンにまたがってデータを保護します。Amazon S3 レプリケーションを使用すると、同じまたは異なる AWS リージョン内のバケット間でデータを自動的かつ非同期にレプリケートできます。 Same-Region Replication (SRR) および Cross-Region Replication (CRR) を使用して、さまざまなユースケースに対応できます。たとえば、CRR は、地理的に異なる場所にデータのコピーを保持することにより、コンプライアンス要件を満たし、レイテンシーを最小限に抑えるのに役立ちます。SRR は、開発者アカウントとテストアカウント間のレプリケーションを設定し、データ主権の要件を満たすために使用できます。どちらの設定でも、Amazon S3 はソースバケット内のすべてのオブジェクトを宛先バケットにレプリケートします。オプションで、レプリケートされるオブジェクトを制御するために、プレフィックスとタグを使用してオブジェクトのサブセットをレプリケートできます。 ソフト削除操作と削除マーカー S3 レプリケーションでは、ソースバケットと宛先バケットの両方でバージョニングを有効にする必要があります。バージョニングされているバケットについて、バージョン ID を指定せずにオブジェクトを削除する場合、この削除操作は、一般に「論理削除」と呼ばれます。 論理削除の結果、「削除マーカー」と呼ばれる新しい null オブジェクトバージョンが生成されます。 オブジェクトは、ライフサイクルの有効期限ポリシーのために削除される場合もあることに留意してください。現在のオブジェクトバージョンが期限切れになると、削除マーカーが追加されます。対照的に、最新でないオブジェクトのバージョンが期限切れになると、永久に削除されます。 ここで興味深い質問が頭に浮かぶことでしょう。すなわち、オブジェクトが論理削除されたときのレプリケーション動作はどうなるのか、ということです。 この場合、2 つの結果があり得ます。 削除マーカーがレプリケートされます (V1 設定)。ソースバケットと宛先バケットの両方で削除されたオブジェクトに対する後続の GET リクエストは、オブジェクトを返しません。 削除マーカーはレプリケートされません (V2 設定)。削除されたオブジェクトに対する後続の […]

Read More

LAMP ベースの多層ウェブアプリケーションを AWS Snowball Edge にデプロイする

遠隔地でアプリケーションを構築していて、モニタリングカメラや検出システムなど、ローカルで生成されたデータに基づいて処理および決定を行う必要があるころを想像してみてください。ネットワークのレイテンシーが長い場合、このようなアプリケーションをクラウドで実行してデータをリアルタイムで処理することはできません。 また、災害から復旧する状況で作業していることもあるでしょう。この場合、クラウドでデータを転送し、処理するのに十分な帯域幅がない可能性があります。また、コンピューティング、ストレージ、ネットワーク、アプリケーションを短時間でデプロイするという制約も加わります。インターネット接続が利用できない場合は、オフラインで実行し、ネットワーク接続が利用できるようになったときにデータをクラウドと同期できるはずです。 AWS Snowball Edge はローカル環境とクラウド間でデータ転送が行える高耐久化されたエッジコンピューティングソリューションです。これは、ネットワークに断続的に接続または切断された環境でコンピューティングインスタンスを実行するのに利用できます。Snowball Edge の運用に必要なインフラストラクチャは最低限でよく、特に専用のデータセンターは必要ありません。Snowball Edge では、さまざまな vCPU とメモリオプションを備えた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成し、アプリケーションをホストできます。これらのユニークな機能により、Snowball Edge は前述のユースケースの理想的なソリューションになっています。 このブログ記事では、Snowball Edge で EC2 インスタンスを起動し、ウェブアプリケーションを起ち上げる方法を詳しく見ていきます。Apache、MySQL、PHP (LAMP)、および人気のあるコンテンツ管理システム (CMS) である Drupal をインストールします。Drupal の動画モジュールを活用して、ここで説明したメディアワークフローの一部を実装できます。このモジュールにより、動画を任意の形式でアップロードし、動画を H.246、Theora、VP8 (ウェブ互換形式) にトランスコードし、サムネイルを作成できます。動画モジュールは、Amazon Simple Storage Service (Amazon S3) を活用するクラウドトランスコーディングサービスである Zencoder、またはサーバーでオープンソースの FFMPEG を使用します。 AWS Snowball Edge の機能 Snowball Edge により、さまざまな vCPU およびメモリオプションを備えた EC2 インスタンスを作成し、アプリケーションをホストできます。Amazon […]

Read More

Amazon S3 バッチオペレーションを使用して保存期間を一括管理する方法

Amazon S3 バッチオペレーションが S3 オブジェクトロックをサポートするようになりました。この記事では、これら 2 つの Amazon S3 機能を一緒に使用して、一般的なデータ保護のニーズに対処する方法を紹介します。S3 バッチオペレーションは、何百万ものオブジェクト間でタグセットをコピーしたり更新したりするなどの反復アクションまたは一括アクションを 1 度のリクエストで実行できる機能です。提供するのはオブジェクトのリストのみで、S3 バッチオペレーションは再試行の管理や進行状況の表示など、すべての手動作業を処理します。S3 バッチオペレーションの詳細については、こちらのブログ投稿をご覧ください。 S3 オブジェクトロックを使用すれば、オブジェクトに保存日と訴訟ホールドを適用して、オブジェクトが無期限、あるいは特定の日付が経過するまで削除または上書きされないようにすることができます。S3 オブジェクトロック向け S3 バッチオペレーションのサポートは、ライトワンスリードメニー (WORM) ストレージの規制要件を満たすのに役立ちます。さらに、オブジェクトを変更または削除する際に保護するためのレイヤーを追加するだけです。 ベーシック Amazon S3 オブジェクトロックには、オブジェクトの保持期間を管理する 2 つの方法があります。 保持期間は、オブジェクトがロックされたままの状態になる固定期間を指定します。この期間中、オブジェクトは WORM で保護されており、オブジェクトのバージョンを削除または変更することはできません。S3 オブジェクトロックは、2 つの保存期間モードを提供します。 ガバナンスモードでは、ほとんどのユーザーによって削除されないようにオブジェクトを保護していますが、保存設定を変更したり、必要に応じてオブジェクトを削除したりする権限をユーザーに付与することもできます。 コンプライアンスモードで保護されたオブジェクトのバージョンは、AWS アカウントのルートユーザーを含め、どのユーザーも上書きまたは削除を行うことができません。 訴訟ホールドは、保持期間として同じ保護を行いますが、期限がありません。代わりに、訴訟ホールドは、明示的に削除するまでその場に置かれたままになります。 オブジェクトのバージョンは、保持期間または訴訟ホールドのいずれか、あるいはその両方の組み合わせを設定できます。たとえば、1 年間の保持時間プラス訴訟ホールドが設定されたオブジェクトをもつ場合があります。正確な保存日がわかる場合は保存期間を使用し、要件に合った保存モードを選択します。 S3 オブジェクトロック向け S3 バッチオペレーションのサポートはいつ使用しますか? バケット内の多数のオブジェクトに S3 オブジェクトロック設定を適用、更新、または削除する必要がある場合は、S3 オブジェクトロック向け S3 バッチオペレーションサポートの使用をご検討ください。S3 オブジェクトロックを初めて使用する場合、S3 オブジェクトロック向け S3 バッチオペレーションのサポートを使えば、これらの変更を簡単に行えます。既存の S3 オブジェクトロック要件が変更され、多数のオブジェクトのロックを更新、追加、または削除する必要がある場合にも当てはまります。オブジェクトがバケットに追加されたときに、S3 […]

Read More

AWS Snowball Edge での AWS Identity and Access Management

お客様の多くは、安全なデータ転送とエッジコンピューティングアプリケーションのために AWS Snowball Edge デバイスを使用しています。最近、AWS は Snowball Edge での AWS Identity and Access Management (IAM) のサポートを発表しました。Snowball Edge に IAM を導入する前まで、IT 管理者はファイルをコピーしたり、コンピューティングワークロードを実行したりするユーザー全員と、単一のアクセスキー/シークレットキーの組み合わせを共有していました。このアクセス方法は、個々のサービスを制御できるほどの詳細度と柔軟性を持ち合わせていませんでした。IAM では、ユーザーが実行できるアクションを制御することにより、Snowball Edge デバイスで実行されている AWS サービスおよびリソースへのアクセスを安全に管理できます。IAM を使用すれば、デバイスユーザーがアクションを実行するために使用するデバイス上のどの AWS リソースも管理することができます。このブログでは、Snowball Edge での IAM 機能を探索し、いくつかの実用的な例を示しています。 概要 Snowball Edge を使用すれば、インターネットへの接続が選択肢にない場所でも、AWS クラウドのストレージとコンピューティングパワーにローカルで費用対効果の高い方法でアクセスできます。オンプレミスのデータセンターと Amazon Simple Storage Service (Amazon S3) の間で数百テラバイトまたはペタバイトのデータを転送できます。さらに、Snowball Edge は特定の Amazon EC2 インスタンスタイプと AWS Lambda 関数を実行する機能を提供するため、オンプレミスまたはクラウドで開発されたアプリケーションを同じデバイスにデプロイできます。Snowball Edge の一般的な使用例には、データ移行、データ転送、データ分析、画像照合、IoT […]

Read More

既存のAWSアカウントを AWS Control Tower へ登録する

AWS Control Tower のリリース後、多くのお客様からいただいていたご要望がありました。既存のAWS Organizations に AWS Control Tower をデプロイすることと、組織が持つ他のアカウントにもガバナンスを拡張することです。 このたび、AWS Control Tower を既存の AWS Organization にデプロイできるようになったことをアナウンスいたします。一方で、AWS Control Tower をデプロイする前に作成した AWS アカウント(ここでは「未登録アカウント」と呼びます)は、デフォルトでは AWS Control Tower ガバナンスの範囲外になります。そのため、これらの未登録アカウントは明示的に AWS Control Tower へ登録する必要があります。 既存アカウントを AWS Control Tower へ登録することで、アカウントベースライン(基本設定)と追加のガードレールが配備され、継続的なガバナンス(Continuous Governance)が有効になります。なお、アカウントを登録する前には、適切なデューデリジェンス(事前評価)を行う必要があります。以下に記載されている「考慮すべき事項」セクションの追加情報を参照してください。 このブログでは、AWS Organizations 内の 未登録 AWS アカウントと 未登録 OU(Organization Units = 組織単位)内のアカウントを、プログラムによって AWS Control Tower へ登録する方法を解説します。

Read More

AWS Config 適合パックを使用したAWS Control Tower発見的ガードレールの実装

多くのお客様から、AWS Control Towerによるガバナンスを実現する前に、Control Towerの発見的ガードレールだけを既存のAWSアカウントに適用したいという要望をいただいています。この度、既存のAWS OrganizationでAWS Control Towerを起動できるようになりました。これにより、お客様は既存のアカウントにてAWS Control Towerの発見的ガードレールのコンプライアンスを適用できるようになりました。加えて、我々はControl Towerの配下にアカウントを登録する機能も発表しました。Control Towerガバナンスをアカウントに拡張する前に、Control Towerのガードレールがアカウントにどのように影響するかを確認することをお勧めします。 このブログでは、AWS Config適合パックを使用してControl Towerガードレールを既存のアカウントに適用する方法を示します。AWS Control Towerに登録する前に、そのアカウントのリソースのコンプライアンスを評価できます。また、適合パックを変更し、管理されていないアカウントに発見的ガードレールのサブセットを適用する方法を示します。最後に、適合パックを使用して、AWS Control Towerがデプロイされていないリージョンに存在するアカウントのリソースを管理する方法を示します。

Read More