Amazon Web Services ブログ

AWS SAM を使用した Kubernetes のサーバーレスアドミッションウェブフックの構築

著者: Simon Woldemichael、アソシエイトソリューションアーキテクト、WWPS ソリューションアーキテクチャ Josh Jiang、アソシエイトクラウド開発者、プロフェッショナルサービス共有配信チーム 学習レベル: 300 Kubernete クラスターでリソースデプロイを制御すると、難しい課題に直面することがあります。たとえば、本番環境に変更をプッシュすると、互換性のないパッケージやサービスをクラッシュさせる脆弱な依存関係をインストールする危険性があります。 Kubernetes のカスタムアドミッションウェブフックを作成すると、規制を厳格に定義し、承認済みリソースをクラスターでのみ起動できます。 次の図は、サンプルのウェブフックのアーキテクチャを示しています。 このブログでは、Kubernetes の開発者とクラスター管理者に向けて、AWS サーバーレスアプリケーションモデル (SAM) を使用してサーバーレスアドミッションウェブフックを作成する方法を解説します。ウェブフックの有用性を示すために、Amazon Elastic Kubernetes Service (EKS) のデプロイを、Amazon Elastic Container Registry (ECR) のイメージに対して検証するようにウェブフックを設定します。 サーバーレスアドミッションウェブフックは、このユースケースに適しています。ですが、Kubernetes リソースの作成、削除、更新に機能を拡張することもできます (Pod など)。最初に、Kubernetes で作成できるウェブフックのタイプについて説明します。次に、構築済みウェブフックをデプロイします。最後に、カスタムウェブフックを作成する方法について説明します。 バックグラウンド Kubernetes クラスターの動的受付制御 Kubernetes がどのように新しいクラスターリソースを内部で調整するかを理解することは、独自のルールを構築するために重要です。Kubernetes ではいくつかのアドミッションコントローラーを使用して、クラスター内のリソースが特定の予想に一致するようにします。これらのアドミッションコントローラーは、有効な作成、更新、削除操作のみを実行できることを保証します。たとえば、存在しないクラスター名前空間に Deployment を作成しようとすると、NamespaceExists アドミッションコントローラーは作成を拒否します。 Kubernetes バージョン 1.9 以降、カスタムプラグインを作成できる 2 つのコードパッケージ (ValidatingAdmissionWebhook と MutatingAdmissionWebhook) が導入されました。これらのプラグインを使用すると、リソースの受付処理に直接統合できます。 ValidatingAdmissionWebhook で、リソースが予想基準に一致するかどうかを検証 できます。たとえば、作成中の Pod には正しいラベルがあり、制限された量の CPU […]

Read More

Amazon EKS コンソールの改善により、クラスターの作成と管理が容易に

先日、AWS は Amazon EKS コンソールにおけるクラスターの作成機能、管理機能、およびサポートドキュメントの使用感を改善したことを発表しました。このブログ記事では、どのような改善が施されたか、またお客様やクラスターの管理者が Amazon EKS コンソールを使用してクラスターを作成する際に、今回の改善がどう役立つかについて詳しく説明します。 1.複数ステップのクラスター作成フロー EKS のコンソールには、複数ステップのクラスター作成フローが追加され、ネットワーキング、ログ記録、タグやシークレットの暗号化といった追加の設定で、クラスターを簡単に作成できるようになりました。今回のアップデートでは、上図や下記のとおり、4 ステップのクラスター作成プロセスが導入されました。 クラスターの設定 ネットワーキングの指定 ログ記録の設定 レビューと作成 2.情報リンクと画面移動のない参照 クラスター作成中に画面を移動しなくてもドキュメントを参照できるよう、入力フィールドに情報リンクが追加されました。リンクをクリックすると、同じページのタブ内に情報が表示されるので、クラスター管理者は情報を参照しやすくなります。クラスター作成フロー中に表示できる新しい情報パネルの一覧を次に示します。 一般的なクラスター設定 (ステップ 1) Kubernetes のバージョン (ステップ 1) クラスターサービスロール (ステップ 1) シークレットの暗号化 (ステップ 1) タグ (ステップ 1) VPC、サブネット、セキュリティグループ (ステップ 2) クラスターエンドポイントアクセス (ステップ 2) コントロールプレーンのログ記録 (ステップ 3) 3.設定の「コンソール内」リフレッシュ クラスター作成の各ステップにおいて、ページ全体をリロードしなくても設定フィールドが動的に更新されるようになりました。また、入力フィールドの横に導入された更新ボタンにより、VPC、サブネット、セキュリティグループ、クラスターサービスロール、KMS キーなど、EKS 外で定義した設定を動的に反映させることができます。この動的更新機能により、コンソールページをリフレッシュすることなしに利用可能なリソースの最新リストをロードできます。 その他のマイナーアップデート クラスター作成後に設定を更新する際に、コンソールから更新タブに移動し、現在のステータスをモニタリングしたり、以前の更新履歴を確認したりできるようになりました。 エンドポイントアクセスを選択するためのトグルボタンがラジオボタンに変更され、クラスターに対して現在どのエンドポイントアクセスオプションが選択されているかが分かりやすくなりました。 複数ステップの設定を反映して、ステップ 4 のクラスターレビューページの編成が変更されました。 クラスター作成レビューページでは、設定情報を失うことなく、各ステップ内で動的に編集できるようになりました。 サブネット/セキュリティグループの選択が、大きなテーブルからコンパクトな複数選択リストになりました。 […]

Read More

Amazon CloudWatch Logs を使用して Amazon Managed Blockchain のアクティビティを追跡する

AWS は最近、Amazon Managed Blockchain と Amazon CloudWatch 間の新しい統合の提供を開始しました。メンバー認証局 (CA)、Hyperledger Fabric ピアノード、およびチェーンコードでのアクティビティなど、ブロックチェーンネットワークでの重要なアクティビティを示す詳細なログを利用できるようになりました。 この投稿では、これらの新機能を使用して、分散型アプリのブロックチェーンアクティビティを追跡する方法を示します。また、Amazon CloudWatch でアラームを作成してブロックチェーンのアクティビティを通知する方法についても説明します。 Amazon Managed Blockchain でロギングを有効化する 始める前に、Amazon CloudWatch Logs でログを有効にして、ブロックチェーンネットワークと Fabric クライアントをセットアップします。詳細については、CloudWatch Logs を使用したブロックチェーンアクティビティのモニタリングを参照してください。 ロギングを有効にできる場所は 2 つあります。メンバーをブロックチェーンネットワークに追加すると、メンバーの認証局 (CA) サービスへのログオンを有効にするオプションが利用できるようになります。次のスクリーンショットを参照してください。 ロギングオプションのいずれかを有効にすると、/aws/managedblockchain/<NetworkID>/<MemberID> という名前のロググループが作成されます。CA ロギングを有効にすると、ca というこのグループの下にログストリームが表示されます。このログストリームには、CA に関連するすべてのアクティビティの詳細なログが含まれています。 ピアノードを作成するときにロギングを有効にすることもできます。ノード上のすべてのアクティビティを表示する詳細なログ (ピアノードログ) またはチェーンコードによって作成されたログを有効にするオプションがあります。次のスクリーンショットを参照してください。 チェーンコードログは、ビジネスワークフローにおける重要なアクティビティを追跡するのに役立ちます。CA およびピアノードのログは、Fabric コンポーネント間の複雑なインタラクションのトラブルシューティングに役立ち、特定のワークロードに関する洞察を得ることができます。 チェーンコードにログメッセージを追加する チェーンコードログ機能は、ビジネスワークフローにおける重要なアクティビティを追跡するのに特に役立ちます。この投稿では、ログを使用して、適切なアクセス許可を持つユーザーのみがチェーンコードの呼び出しを実行できることを確認し、ユーザーが不正なアクセスを試みたときにアラートを発生させる方法を示します。これらの機能をテストし、CloudWatch アラームを有効にして、不正アクセス試行について通知するには、ネットワークに次のコードをデプロイします。/home/ec2-user/permissions-example/index.js の Fabric クライアントのホームフォルダに次のコードを保存します。 ///////////////////////////////////////////////////////// // ROLE-BASED ACCESS CONTROL EXAMPLE // […]

Read More

Amazon Personalize を使ったオムニチャネルでのパーソナライゼーション

顧客とブランドとの接点となるタッチポイントが、デジタルとリアルライフとの入り組んだ関係に変化していくなか、顧客を引き付けるためのパーソナライズされた体験を販売チャネルをまたいで提供することは、気が遠くなる程の大仕事になっています。同時に、顧客からの期待度も増大し続けます。モバイル、ウェブ、E メール、SMS、問い合わせセンター、そして対面を通じた接触の間で、シームレスに体験が移行できない場合、現代の顧客は急速にブランドへの関心を低下させるのです。 Amazon Personalize では、機械学習 (ML) アルゴリズムを応用して、キャンペーンと呼ばれるパーソナライズされたレコメンデーションを生成します。これは、履歴からユーザーの好みを学習するとともに、ユーザーが関心を膨らませている対象にもリアルタイムで適応できるものです。このパワフルなツールは、真にパーソナライズされた顧客体験を生み出すための力になります。しかしながら、Amazon Personalize を別々のチャネル間に配置するためには、そこでの体験を機能させるのに必要なアーキテクチャやツールに関しての、熟慮されたアプローチが必要となります。 この記事では、3 つの一般的なチャネル、つまり、ウェブとモバイルのアプリケーション、メッセージ、そして対話を通じパーソナライズされたレコメンデーションを提供するサンプルのフルスタック E コマースアプリケーションに、Amazon Personalize を統合する方法をご紹介します。分離されたマイクロサービスアーキテクチャをいくつかの AWS Lambda 関数と組み合わせることで、Amazon Personalize のキャンペーンが利用できるようになり、また、各チャネル間で顧客の意図を追跡できるようになります。次の図に、今回のソリューションを示します。   ソリューションの概要 このソリューションは、GitHub レポジトリ、Retail Demo Store の一部として提供されます。このプロジェクトでは、ウエブ、モバイル、メッセージ、および対話の各オムニチャネルで、パーソナライゼーションの提供方法を紹介するフルスタックの E コマース用サンプルウェブアプリケーションを、お使いの AWS アカウントにデプロイします。このアプリケーションは、次に示すような複数のデバイスタイプに対応し、他の多くの業界向けのモデルとしても使用できるような、典型的な E コマース/小売りのユースケースとなっています。 次の図は、この記事で扱うアーキテクチャにおける各部の関係を示しています。この記事では、Amazon Personalize の単一デプロイから、3 つの異なるコミュニケーションチャネル全体に対し、パーソナライズしたレコメンデーションを供給する方を見ていきます。真のオムニチャネルでのユーザー体験にとって、曖昧ながらも多くの場合に重要であり、このユースケースにおいて共有された Amazon Personalize キャンペーンを使う理由ともなる要件とは、全チャネルを通じて同じ論理ユーザーを特定可能にするということです。そしてもちろん Amazon Personalize では、ユーザーが膨らませている関心にもリアルタイムで適応できるのが、最もパワフルな機能の 1 つとなっています。このことは、次に示すアーキテクチャにより、リアルタイムのレコメンデーションを複数のチャネルに拡張することで実現されます。 多くの企業が顧客とのつながりを保つために使う主要なチャネルは、モバイルとウェブのアプリケーションです。前出の図の中で 1、2、および 3 として描かれているこのチャネルでは、モバイルもしくはウェブアプリケーションが Amazon Personalize に対しクリックストリームイベントを送信することでリアルタイムのレコメンデーションを実現しています。同時に、パーソナライズされた製品レコメンデーションを、Amazon Elastic Container Service […]

Read More

Amazon RDS for SQL Server での Microsoft SQL Server Reporting Services の設定

Microsoft SQL Server Reporting Services (SSRS) を Amazon Relational Database Service (RDS) for SQL Server DB インスタンスで直接実行できるようになりました。SSRS は、SQL Server 2017 Standard または Enterprise エディションの シングル AZ またはマルチ AZ インスタンスでアクティブ化できます。SSRS を Amazon Elastic Compute Cloud (Amazon EC2) で実行する場合は、SSRS を Amazon RDS for SQL Server で直接実行することによってコストを節約できるようになります。Amazon RDS for SQL Server は、SQL Server データベースと同じ RDS DB インスタンスで Report […]

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

PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離

Software as a Service (SaaS) プロバイダーには、基本的にテナントデータの分離を適用する責任があります。テナントの 1 つが別のテナントのデータにアクセスした場合、信頼はなくなり、ビジネスのブランドに永久的な損害を与える可能性があるだけでなく、さらにひどい場合には、ビジネスを失う可能性があります。 リスクが非常に大きいため、効果的なデータの分離を計画することが重要です。マルチテナントアーキテクチャは、各テナントのリソースをレプリケートするのではなく、すべてのテナントのデータストレージリソースを共有することで、俊敏性と運用コストを節約します。しかし、共有モデルで分離を適用することは難しいため、マルチテナントデータモデルで妥協して、テナントごとにコストがかかるデータベースのオプションに戻すことが可能です。 多くの場合、共有データベースモデルはソフトウェア開発者に依存しているため、記述してあるすべての SQL ステートメントで適切なチェックを実装することが唯一の選択となります。他のセキュリティ上の懸念事項と同様に、日常的なソースコードの変動性にあまり依存しないより一元的な方法で、テナントデータの分離ポリシーを適用するのがよいでしょう。 この投稿は SaaS アーキテクトと開発者を対象としており、テナントの共有データベースの利点を享受しながら一元型分離の適用を実現する方法について解説しています。 データパーティション分割のオプション マルチテナントシステムで使用する一般的なデータパーティション分割モデルには、サイロ、ブリッジ、プールの 3 つがあります。各モデルの分離方法には、それぞれ長所と短所があります。 サイロ – テナントごとに個別のデータベースインスタンスを使用すると、分離はたいていインフラストラクチャコストが高くなるだけでなく、テナントのセットアップがより複雑になります。これは、SaaS のサービスにオンボードする各テナントに、新しいデータベースインスタンスを作成および管理する必要があるためです。 ブリッジ – テナントデータをパーティション分割する 2 つ目のアプローチは、同じデータベースインスタンスを共有しながら、テナントごとに異なるスキーマを使用する方法です。リソースを共有することでモデルのコストを削減できますが、メンテナンスとテナントのセットアップはかなり複雑になる可能性があります。 プール – 3 つ目のパーティション分割モデルは、共有データベースインスタンスと名前空間の両方を使用するものです。この設計ではすべてのテナントデータを並べて表示しますが、各テーブルまたはビューには、データのフィルターに使用するパーティション分割キー (通常はテナント ID) が含まれています。 プールモデルは運用コストが最も節約でき、インフラストラクチャコードとメンテナンスのオーバーヘッドを削減します。ただし、このモデルはデータアクセスポリシーを適用するのが難しい場合があり、通常は、すべての SQL ステートメントに正しい WHERE 句を実装することが望まれます。 マルチテナントデータのパーティション分割の詳細については、次の AWS SaaS Factory ホワイトペーパーをご参照ください。 行レベルのセキュリティ RDBMS 分離ポリシーの適用をデータベースレベルで一元化することにより、ソフトウェア開発者の負担を軽減できます。このため、プールモデルの利点を活用し、かつテナント間のデータアクセスのリスクを軽減できます。 PostgreSQL 9.5 以降には、行レベルセキュリティ (RLS) と呼ばれる機能が含まれています。テーブルにセキュリティポリシーを定義すると、これらのポリシーが、SELECT クエリによって返されるそのテーブルの行、または INSERT、UPDATE、DELETE […]

Read More

Amazon DocumentDB (MongoDB 互換) について知っておくべき 12 のこと

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 AWS は、可用性、信頼性、耐久性、スケーラビリティ、バックアップなどに関するお客様の課題を独自の方法を用いて解決するために Amazon DocumentDB を構築しました。その過程において、当社は、付加価値を生まない手間のかかる作業を取り除き、コストを削減するために、いくつかの斬新でユニークな機能を構築しました。この投稿では、Amazon DocumentDB で MongoDB ワークロードを構築およびスケーリングするのに役立つ、まだ認識されていないかもしれない 12 の Amazon DocumentDB 機能を紹介します。 1.最新のクラウドネイティブアーキテクチャ Amazon DocumentDB は、クラウドネイティブのデータベースアーキテクチャを使用してゼロから構築されました。独自のアーキテクチャによりストレージとコンピューティングが分離されているため、各レイヤーを個別に拡張できます。Amazon DocumentDB は、3 つの AWSアベイラビリティーゾーン (AZ) にまたがって 6 つの方法でデータをレプリケートすることで高可用性と耐久性を備えた、フォールトトレラントな分散型の専用自己修復ストレージシステムを使用しています。詳細については、YouTube のAWS re:Invent 2019: Amazon DocumentDB の詳細の動画をご覧ください。次の図は、Amazon DocumentDB アーキテクチャにおけるコンピューティングとストレージの分離、およびデータが 3 つの AZ にまたがって 6 […]

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 RDS for PostgreSQL で高速リフレッシュ機能を構築する

この記事は CDL によるゲスト投稿です。CDL は自社を次のように紹介しています。「CDL は英国を拠点とする主要なインシュアテック企業であり、Financial Times 誌の業界に影響を与えている高成長の英国企業 Future 100 のリストに掲載されています。保険と金融サービスの分野で強力な実績を残し、そのソリューションは英国で最も収益性の高い保険代理店を支えています。 CDL はシステム上で 700 万件を超える保険契約を取引し、Sainsbury’s Bank、Tesco Bank、Swinton Insurance、Moneysupermarket.com などをクライアントに抱えています」 この記事では、CDL が Amazon RDS for PostgreSQL のマテリアライズドビューログをどう使って高速リフレッシュ機能を開発したかについて説明します。変更を追跡するために構築したものを詳述し、完全リフレッシュに代わる代替手段を示します。これにより、必要な時間が数時間から数秒に短縮されました。また、高速リフレッシュを可能にするためのオープンソースソフトウェアをより広い PostgreSQL コミュニティと共有し、関連するインストールプロセスの概要を示します。 課題 CDL は毎日数百万のトランザクションを処理しています。当時はビジネスインテリジェンス (BI) プラットフォームを Oracle から PostgreSQL に移行することを検討していました。切り替えを実際に行うには、お客様が最新のビジネスインテリジェンスへ引き続きアクセスできるようにするため、リレーショナルデータベースでこの大量の変更を処理し、ほぼリアルタイムでリフレッシュする必要がありました。 PostgreSQL は完全リフレッシュ機能のみを備えています。けれども、Google のサービスレベルアグリーメントでは 15 分ごとにデータをリフレッシュする必要があります。そして CDL は大量の変更を処理していることから、完全リフレッシュプロセスではこのタイムスケール内でこの規模のマテリアライズドビュー (MV) を処理することは不可能でした。当社の最大の MV ログは 150 GB を超えており、完全リフレッシュプロセスでは構築するのに何時間もかかります。またお客様によっては、1 日あたりのビュー数が 150 回を超える方もいらっしゃいます。 当社は、BI ソリューションの MV […]

Read More