Amazon Web Services ブログ

シークレット情報の安全な格納、配布、および交換

当社は AWS Secrets Managerの提供を開始しました。これにより、API または AWS コマンドラインインターフェイス (CLI) を使用して、シークレットを格納および検索すること、ならびに内蔵またはカスタムの AWS Lambda 関数を使用して、資格証明を交代させることが容易になりました。1 つのマシン、1 つのアプリケーションで作業している場合、データベースの資格証明、パスワード、あるいは API 鍵など、アプリケーションのシークレットの管理は簡単です。多くの分散化したマイクロサービスにまで成長してスケーリングされると、シークレットを安全に、格納、配布、交換、使用する作業は、厄介な作業になります。以前は、顧客はシークレット管理専用の追加インフラストラクチャをプロビジョニングして維持管理する必要がありました。これにはコストがかかり、システムには不必要な複雑性が導入されました。 AWS シークレットマネージャー Twitter からの入力ツイートを受け取って、それらを Amazon Aurora データベースに格納するアプリケーションがあると仮定してください。以前は、データベース管理者からユーザー名とパスワードが求められるため、環境変数、本番へのレース、あるいはアプリケーション自体に、これらの資格証明を組み入れておく必要がありました。また、ソーシャルメディアマネージャーに、Twitter API 資格証明の作成と、それらの格納方法の説明を求める必要もありました。これは複数の人を関与させる、手間のかかるプロセスですが、資格証明を交換するたびに必要なプロセスでした。シークレットマネージャーが利用できるようになったので、データベース管理者は資格証明をシークレットマネージャーに一度入力しておけば、後はシークレットマネージャーのラムダ関数に、自動的に資格証明を更新したり交換したりするのを任せておくことができます。ソーシャルメディアマネージャーが Twitter の API 鍵をシークレットマネージャーに入力してくれれば、単純な API 呼び出しにアクセスしたり、プログラムで Twitter の API を呼び出すカスタムラムダ関数を使って、これらを交換したりすることができるようになりました。シークレットは自分のアカウントで選択する KMS 鍵に基づいて暗号化され、管理者は個々のロールまたはユーザーのための粒度の細かい IAM ポリシーに基づいてこれらのシークレットへの明示的にアクセス権を承認します。 AWS シークレットマネージャーのコンソールを使ってシークレットを格納する方法を説明します。最初に、[Store a new secret (新規シークレットの格納)] をクリックして、新規シークレットウィザードを表示します。RDS Aurora インスタンスの場合、インスタンスを選択して、初期のユーザー名およびパスワードを入力することにより、データベースに接続します。 次に、簡単な説明と名前を入力することによって、シークレットにアクセスします。ここでは任意の命名スキームを使用することができます。 次に、10 日ごとにパスワードを入れ替えるために、シークレットマネージャーに付属しているラムダ関数の交換機能を構成します。 最後に、すべての詳細情報をチェックして、シークレットの格納および検索のためのサンプルコードを完成します。 その結果、シークレットはコンソールで表示できるようになりました。 シークレットには、必要に応じて、API を呼び出すことでアクセスすることができます。 […]

Read More

AWS 構成ルールの更新: アカウントおよびリージョンにまたがる集約コンプライアンスデータ

既に述べたことがありますが、高度な AWS 顧客は複数の AWS アカウントを制御していることが常です。これらのうちのいくつかは、買収、またはボトムアップからの持ち越し、クラウドコンピューティングの部門採用の結果です。また人によっては、開発者、プロジェクト、部門で区別するために、複数のアカウントを作成することがあります。私たちは、これをアカウントのポリシーベース管理のためにベストプラクティスとして採用し、多くの AWS サービス、ならびに AWS Organizations のクロスアカウント機能で補強することを強く支持します。また、これらの顧客は AWS Config を十分に活用しており、Config Rules (自分で作成したもの、および Config から提供されたもの) を使用して AWS リソースのコンプライアンスをチェックします。 アカウントおよびリージョンにまたがる集約 現在私たちは、複数の AWS アカウントおよびリージョンにまたがるルールによって生成されたコンプライアンスデータを集約する機能を追加することによって、さらに役立つ Config Rules を作成することを可能にしました。集約データは、単一のダッシュボードに表示することができるので、ガバナンスとコンプライアンスを改善するための優れた手段になります。さらに良いことに、集約機能とダッシュボードは、AWS Config ユーザーであれば無料で利用することができます。 これのセットアップ方法を簡単に説明します。最初に、いくつかの用語を定義しておきます。 aggregator – これは新規の Config リソースです。これは集約対象となるコンプライアンスデータのソース (アカウントおよびリージョン) を特定します。複数の aggregator を同時に使用できるので、ガバナンスおよびコンプライアンスモデルをさらに細かくチューニングすることができます。 aggregator アカウント – これは 1つ以上の aggregator を所有する AWS アカウントです。 ソースアカウント – これは集約対象のコンプライアンスデータを持つ AWS アカウントです。 集約ビュー – […]

Read More

AWS ファイアウォールマネージャー – ウェブアプリケーションポートフォリオの集中管理

特に大規模な組織では、しばしば、分散制御と集中化制御との間で論争が起きます。分散制御モデルの場合、特殊化したローカルなニーズに対して、迅速に対応することができますが、集中化制御モデルの場合、すべてのチームが関与するグローバルなイニシアチブや課題に対して、適切なレベルの監視を行うことができます。 私たちは、AWS 顧客のアプリケーションの適用範囲が、多数の AWS リージョン、AWS アカウント、開発チーム、およびアプリケーションを含むようになったとき、この問題が発生することを見てきました。顧客は、AWS がリソースを最適の場所にデプロイしつつ、敏捷性および反応性を向上させているという事実に惚れています。しかし、この多様性とスケーリングは、セキュリティやコンプライアンスの観点からは、新しい課題を露呈します。自由なイノベーションは、重要なデータを保護し、脅威が出現したときに迅速に対応するというニーズとバランスが取れている必要があります。 ここ数年当社は、AWS WAF や AWS シールドなど、保護機能の広範囲にわたるセットを提供してきました。当社の顧客はこれらのオプションを最大限に活用してきましたが、一方で、単一の集中化した場所から管理する機能を求める声も多く聞かれました。 AWS ファイアウォールマネージャーの登場 AWS ファイアウォールマネージャーはまさにこのような顧客のために作られました。これは、組織のセキュリティの設定およびプロファイルの集中化制御を管理しつつ、顧客には、複数の AWS アカウントの使用して、必要ないかなるリージョンにおけるアプリケーションをもホストするという自由を与えることを実現します。開発者は開発が可能になり、革新者は革新が可能になる一方で、セキュリティイチームは、潜在的脅威および実際の攻撃に、迅速、統一的、かつグローバルに対応する能力を獲得します。 セキュリティチームは、ファイアウォールマネージャーを使用した場合、アカウントおよびアプリケーションすべてを対象とする自動ポリシー強制機能を通じて、新規および既存のアプリケーションが組織全体のセキュリティポリシーを遵守することを確信することができます。セキュリティチームは、対策が不十分なアプリケーションや AWS リソースを見つけた場合、数分以内にコンプライアンスを確立することができます。 ファイアウォールマネージャーは、WAF ルールセットおよびオプションの AWS シールドアドバンストプロテクションを含む名前付きポリシーを中心に構築されます。各ポリシーは、アカウント、リソースタイプ、リソース ID、またはタグによって指定される、特定の AWS リソースセットに適用されます。ポリシーは、マッチングしたすべてのリソースに自動的に適用されます。またはあなたが選択するそのサブセットに適用されます。ポリシーには、組織のポリシーから抽出した WAF ルール、ならびに、Imperva、F5、Trend Micro、その他 AWS マーケットプレースのベンダーなど、AWS パートナーによって作成された WAF ルールを含めることができます。これにより、セキュリティチームは、既存のオンプレミスセキュリティ環境をクラウド内で再現することができます。 ツアーを見る ファイアウォールマネージャーには次の 3 つの前提条件があります。 AWS Organizations – 組織はアカウントを管理するために AWS Organizationsを使用して、すべての機能を有効にしておく必要があります。詳細については、「組織の作成」を参照してください。 ファイアウォール管理者 – 組織内の AWS アカウントの 1 つをファイアウォールマネージャーの管理者として指名する必要があります。これによって、そのアカウントには、組織全体に AWS WAF […]

Read More

Apache MXNet Model Server が規模に応じたモデルサービングのために最適化されたコンテナイメージを追加

AWS は、本番ユースケースのためのモデルサービングのデプロイメントを効率化する Apache MXNet Model Server (MMS) v0.3 をリリースしました。このリリースには、GPU および CPU 上の深層学習ワークロード用に最適化された事前構築済みのコンテナイメージが含まれています。これによって、エンジニアはスケーラブルなサービングインフラストラクチャをセットアップできるようになります。Apache MXNet Model Server (MMS) と、規模に応じて深層学習モデルを提供する方法の詳細については、この先をお読みください! Apache MXNet Model Server (MMS) とは? MMS は、オープンソースのモデルサービングフレームワークで、規模に応じて深層学習モデルをデプロイするタスクをシンプル化するように設計されています。以下は MMS の主な利点の一部です。 MXNet と ONNX のニューラルネットワークモデルを単一のモデルアーカイブにパッケージ化するためのツール。これは、モデルを提供するために必要なアーティファクトのすべてをカプセル化します。 モデルアーカイブにパッケージ化されたカスタムコードを使用して推論実行パイプラインの各ステップをカスタマイズする機能。これは、初期化、前処理、および後処理の上書きを可能にします。 事前設定されたサービングスタック (REST API エンドポイントを含む) と推論エンジン。 スケーラブルなモデルサービングのために事前構築および最適化されたコンテナイメージ。 サービスとエンドポイントを監視するためのリアルタイムの運用メトリクス。 このブログ記事では、コンテナを使用して MMS を本番環境にデプロイする方法、クラスターを監視する方法、およびターゲットの需要に応じてスケールする方法を見て行きます。 コンテナでの MMS の実行 スケーラブルな本番用スタックのセットアップに進む前に、コンテナで MMS を実行する方法を確認しましょう。これを理解しておくことは、スケーラブルな本番クラスターのより複雑なセットアップについて考察するときに役立ちます。 この新リリースでは、事前構築され、最適化された MMS コンテナイメージが Docker Hub に発行されます。これらのイメージは、CPU ホスト […]

Read More

APNパートナーLinkeによるSAPワークロードにおけるAWSの力の活用

AWSでパートナー ソリューション アーキテクトを務めるFrancisco Javier Garcia Romeroによる記事です。 企業の中核となるSAPワークロードに対するAmazon Web Services (AWS)の採用の速度は、過去数年間着実に拡大し続けています。2018年も既に、AWSクラウドへのSAPワークロードの移行と展開における需要と関心がこれまで以上に高まっていることを感じています。 AWS Partner Network (APN) プレミアコンサルティングパートナーでAWS SAPコンピテンシーを保有するLinkeは、新しいSAPの導入、SAP HANAへのデータベース移行、あるいはAWSサービスとSAPシステムの統合プロジェクトを含む、SAPを中心とした企業のデジタル変革戦略の実行を支援します。

Read More

APNパートナーLemongrassのMiCloudによるSAPを中心とした組織の変革

AWSでSAP専門のパートナー ソリューション アーキテクトを務めるJohn Studdertによる記事です。 SAPは世界中の大企業の中枢を担うミッションクリティカルなソフトウェアを提供していることで知られています。私たちのお客様の多くは、重要なSAP本稼働システムをAmazon Web Services (AWS)上で長年にわたって運用してきました。 AWS Partner Network (APN) アドバンスドコンサルティングパートナーでAWS SAPコンピテンシーを保有するLemongrassは、2010年以降、SAP on AWSだけに注力しています。お客様の移行と構築作業において一貫して大きな成果を上げており、さらにMiCloudアプリケーションスイートによるマネージドサービスを提供しています。

Read More

分散型可用性グループを使用して、ハイブリッドMicrosoft SQL Serverソリューションを設計する方法

モノリシックでミッションクリティカルなMicrosoft SQL ServerデータベースをオンプレミスからAWS(Amazon EC2ベースのSQL Server)に移行することは、しばしば困難な作業です。主な課題は次の通りです: 継続的なダウンタイム – ビジネスに悪影響を及ぼす可能性のあるカットオーバー中の継続的なダウンタイムウィンドウが発生する課題 データ同期の課題 – オンプレミスに配置されたデータベースとAWS上のデータベースを同期した状態に維持するための課題 柔軟性の欠如 – 移行のための段階的なアプローチを計画・実行する為の柔軟性を確保する課題 この記事では、重要なSQL ServerデータベースをAWSにリフト&シフト(またはリフト&トランスフォーム)するためのハイブリッドソリューションの構築方法について詳しく説明します。このソリューションでは、SQL Server 2016で導入された新しい機能である分散型可用性グループを使用します。この記事では、分散型可用性グループを使用して移行を制御し、柔軟性を高める段階的アプローチについても説明します。 分散型可用性グループの概要 分散型可用性グループは、2つの個別の可用性グループにまたがる特別なタイプの可用性グループ(AG)です。分散型可用性グループは複数の可用性グループの1つ(または複数のAGの中の1つ)と考えることができます。基礎となる可用性グループは、2つの異なるWindows Server Failover Cluster(WSFC)で構成されます。 分散型可用性グループアーキテクチャは、既存のオンプレミスWindows Server Failover Cluster(WSFC)をAWSに拡張するよりも効率的です。データは、オンプレミスのプライマリからAWS上の1つのレプリカ(フォワーダ)にのみ転送されます。フォワーダは、AWS上の他のリードレプリカにデータを送信する役割を担います。このアーキテクチャにより、オンプレミスとAWSの間のトラフィックフローが削減されます。 アーキテクチャ概要 次の図は、ソリューションの全体的なアーキテクチャを示しています。 図に示されているように、最初のWSFCクラスタ(WSFC1)はオンプレミスでホストされています。オンプレミス可用性グループ(AG1)はこのWSFCクラスタに配置されます。 2番目のWSFCクラスタ(WSFC2)はAWSでホストされます。 AWS可用性グループ(AG2)はこのWSFCクラスタに配置されます。 このユースケースでは、オンプレミスのSQL Serverインスタンスとデータベースは、従来の物理サーバーまたは仮想マシン(VM)によってホストされています。 AWSのSQL ServerインスタンスはAmazon EC2でホストされ、SQL ServerデータベースはAmazon EBSボリュームで構成されます。 AWS Direct Connectによって、オンプレミスからAWSへの専用ネットワーク接続を確立しています。 前述のアーキテクチャ図に示すように、オンプレミス可用性グループ(AG1)には2つのレプリカ(ノード)があります。これらの間のデータ転送は、自動フェイルオーバーを使用して同期します。オンプレミスレプリカの1つに障害が発生すると、AGは2番目のレプリカにフェールオーバーすることで、アプリケーションとユーザーはDBを使用できます。各可用性グループは、1つのプライマリレプリカと最大8つのセカンダリレプリカをサポートしています。高可用性の要件と拡張性のニーズに基づいて追加のレプリカを同期または非同期にする必要があるかどうかを判断します。 AWS可用性グループ(AG2)にも2つのレプリカがあり、それらの間のデータ転送は自動フェールオーバーで同期しています。 EC2インスタンスまたは1つのアベイラビリティゾーンに障害が発生すると、AGは別のアベイラビリティゾーンにある2番目のEC2インスタンスにフェールオーバーします。 このソリューションの一環として、分散型可用性グループを構成します。このグループには、オンプレミス可用性グループ(AG1)とAWS可用性グループ(AG2)の両方が含まれます。分散型可用性グループは、前述の図において赤い点線で示すように、データベースを非同期で同期させます。 フォワーダ(前述の図で緑文字で表されている)は、AWS内の他のリードレプリカにデータを送信する役割を担います。このデータ転送により、オンプレミスとAWS間のトラフィックフローが減少します。オンプレミスからAWSへのデータ転送はプライマリレプリカから一度だけ実施され、フォワーダは残りの伝播を処理します。 どの時点でも、書き込みに使用できるデータベースは1つだけです。残りのセカンダリレプリカデータベースは読み取り用に使用できます。前述のサンプルアーキテクチャ図では、社内のプライマリデータベースを読み取り/書き込み可能にし、AWSセカンダリデータベースを読み取りに使用できます。 AWSでリードレプリカを追加できることが重要なメリットです。この能力があれば、AWSへの移行に際して、読取り専用アプリをAWSに最初に移行することができます。また、データベースは、AWS上のアプリケーションとそのユーザーにも近くなります。 読み込みのワークロードをスケールアウトする場合は、AWSにさらに多くのリードレプリカを追加できますし、複数のアベイラビリティゾーンに配置することも可能です。このアプローチは、以下のアーキテクチャ図で表されます。この図では3つの異なるアベイラビリティゾーンに、それぞれリードレプリカを配置しています。 段階的な移行方法 分散型可用性アーキテクチャを使用することで、段階的な移行が可能となり、移行における柔軟性を高めることができます。 フェーズ1 この段階では、ほとんどの読取り専用アプリケーションをAWSに移行して、AWS上の読取り専用セカンダリデータベースにアクセスします。読み取り/書き込みを行うアプリケーションは、引き続きオンプレミスのプライマリ・データベースにアクセスします。 クラウド移行のこのフェーズでは、ストレステスト、機能テスト、およびデータベース作業負荷の回帰テストが重要な要素です。読取りワークロードをサポートするためにEC2インスタンスを正しくサイジングすることもこのフェーズの重要なステップです。 […]

Read More
Perform unit tests through AWS CodeStar

AWS CodeStar プロジェクトにおける単体テストの実行

このブログ記事では、AWS CodeStar プロジェクトの一部として単体テストを実行する方法についてご紹介します。AWS CodeStar は AWS 上でアプリケーションを素早く開発、ビルド、そしてデプロイするのに役立ちます。AWS CodeStar を使えば、継続的デリバリ(CD)のツールチェーンを構築しソフトウェア開発を一箇所に集約して管理することができます。 単体テストはアプリケーションのコードの個々の単位をテストし、問題を素早く特定し取り去るのに役立ちます。単体テストは、自動化された CI/CD プロセスの1部分を構成することで、バッドコードが本番環境にデプロイされてしまうことを防ぐのにも役立てられます。 多くの AWS CodeStar プロジェクト テンプレートには、単体テストのフレームワークがあらかじめ設定されています。そのため、自信を持ってコードのデプロイを開始することができるでしょう。この AWS CodeStar プロジェクトの単体テストは、ビルドステージにおいて実行されるように設定されているので、もし単体テストがパスしなかったらそのコードがデプロイされることはありません。単体テストを内包している AWS CodeStar プロジェクト テンプレートの一覧については、AWS CodeStar ユーザガイドの AWS CodeStar プロジェクト テンプレートを参照してください。

Read More

P2Pからクラウドへの移行: For HonorとFriday the 13th The Gameがどのようにプレイヤー体験を向上させたのか

ゲーム開発者として、ローンチに至るまで情熱を絶やさずゲーム開発とファンコミュニティの育成に数年の歳月と投資をされてきたかと思います。最高のユーザー体験を提供することおいては、例えばネットワーク接続時のプレイヤーの待ち時間に対するバックエンドの選択肢等バックエンドインフラは一番の関心ごとではなかったかもしれません。 多くのゲーム開発者がピア・ツー・ピア(P2P)ネットワークでマルチプレイヤータイプのゲームを実現させています。開発当初は一見してコスト効果の高いソリューションに思えますが、我々は沢山の開発者がP2Pから クラウド上で可動する専用ゲームサーバー に切り替えられる案件を見てきました。ここでは、UbisoftやIllFonicのようなスタジオのFor HonorやFriday the 13th The Gameのチームが、なぜP2Pをやめクラウド上の専用ゲームサーバに乗り換えたのか、その理由のいくつかを見てみたいと思います 劣悪なレイテンシーと接続性からの脱却 P2Pネットワークでは同一エリアで強力なネットワーク接続があれば低レイテンシーな体験をプレイヤーにもたらしてはくれます。しかしながら、P2Pネットワークでの全体的なゲームのレイテンシーは、ホストとのネットワーク接続のレイテンシーに縛られます。 For Honorは、当初、P2Pネットワークモデルを採用してリリースされました。時間を経るに連れ、プレイヤーの体験に関してアーキテクチャの選択に起因するいくつかの問題がある事が明らかになり、セッションの移譲とNAT (Network Address Transaction) の問題解決やマッチメイキングとオンライン体験の安定性を得るために、UbisoftはAmazon GameLiftで稼働させる専用ゲームサーバモデルに移行する事を決定しました。 専用ゲームサーバは開発者側による細かな制御を可能にします。さらに、クラウド上でのホスティングを利用する事で、プレイヤーを低レイテンシーで安定したゲームサーバに接続する等の管理も容易にできるようになります。 ドロップアウト、ホストの優位性、マルチプレイヤーゲームのチート対策 プレイヤーは、ネット接続の問題、ゲームへの興味喪失等々様々な理由でゲームセッションからドロップアウトします。 ホストプレイヤーがゲームから抜けると、他の全てのプレイヤーのゲームの中断や瞬断を招きます。Friday the 13th The Game独自のユニークな非対称マルチプレイゲームではこの問題はより顕著でした。このゲーム内では、あの悪名高いジェイソンはマッチ中の他の全てのプレイヤーと敵対します。ホストプレイヤーがジェイソンに倒された場合に、墓からの観戦は望まずゲームからドロップアウトしてしまうので、全てのプレイヤーのゲームが中断してしまっていました。 P2Pネットワークでは不正やチートも容易にできてしまい、ホストはレイテンシー的に優位になる事が多々ありました。また、専用サーバモデルアーキテクチャに比べ、ホストプレイヤーのPCが認証を行うP2Pモデルではチートの検出も容易ではありませんでした。そして、ホストは他のプレイヤーに比べてレイテンシーが低いので度々優位になりました。専用サーバモデルを採用することで、ゲームの中断やチートの問題を抑え、全てのプレイヤーに平等なゲームプレイ体験を提供できるようになります。これらがIllFonicがAmazon GameLift上で専用サーバを稼働させるという選択をされ、マルチプラットフォーム(PC、Xbox One、PS4)間プレイを実現するに至った理由です。 UbisoftとIllFonicによるP2Pと専用サーバの知見がGDC 2018でシェアされました GameLiftチームによる「Exploring Trends of Multiplayer Game Infrastructure with Amazon Gamelift」セッションをぜひご確認ください。 UbisoftよりFor Honor開発者のDamien KiekenとRoman Campos Oriolaが、IllFonicよりFriday the 13th The Gameの技術ディレクターPaul Jacksonにより、彼らのバックエンドインフラやP2PネットワークからAmazon GameLift上の専用ゲームサーバへの移行に関してご紹介いただきました。また、Amazon GameLiftチームからもマルチプレイヤーゲームサーバのトレンドやマシンラーニング等も紹介されます。 GDC 2018 @ […]

Read More

Database Migration Playbook が公開されました!

Database Migration Playbooks(Amazon Web Services と NAYA Tech の共同プロジェクト)とは、異種間データベース移行計画を成功させるためのベストプラクティスに焦点を当てた一連のガイドです。このプレイブックは、AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Servies (AWS DMS) を含む、既存の自動化および半自動化されたAmazonデータベース移行ソリューションおよびツールを補完するものです。

「Oracle to Amazon Aurora Migration」プレイブックの初版では、Oracle 11g と12cのデータベース機能とスキーマオブジェクトを Amazon Aurora with PostgreSQL compatibility に移行するためのベストプラクティスに重点を置いています。移行するためには、PostgreSQLデータベースエンジン自体に組み込まれている機能と、様々なAWSサービスやソリューションの両方を使用しています。

Read More