Author: AWS Japan Staff


発表: Amazon GameLift がすべての C++ と C# ゲームエンジンをサポート

すべてのゲーム開発者の方にお知らせします。数週間前にサンフランシスコで行われた GDC 2017 は大人気でした。そのため、クールなゲームの学習と構築に刺激を受け、情熱を注ぐには今が最適なタイミングです。ここで、Amazon GameLift がすべての C++ と C# ゲームエンジンで利用可能になったことをお知らせします。これには、Amazon Lumberyard、Unreal Engine、Unity が含まれ、そのすべてでゲームセッションのマッチング機能が向上しています。Amazon GameLift に詳しくないお客様向けに、ゲーム開発者が楽しく革新的なオンラインゲーム体験を提供できるよう支援するために設計された、このマネージド型サービスについてご紹介します。

Amazon GameLift は、専用ゲームサーバーをホストするためのマネージド型の AWS のサービスで、ゲーム開発者が簡単にゲームのキャパシティーをスケールし、利用可能なゲームセッションでプレイヤーをマッチングできるようにします。Amazon GameLift を使用すると、サーバーのホスト、ゲームの可用性の追跡、分散サービス拒否 (DDoS) 攻撃からのゲームサーバーの防御が可能なほか、ゲームをオフラインにすることなくアップデートをデプロイできます。Amazon GameLift サービスは Amazon Game Studios の専用ゲームサーバーや外部のゲーム開発顧客に役立ち、指定された時間内に開始、終了するゲームループで、セッションベースのゲームをサポートするよう設計されています。最新の Amazon GameLift リリースではサービスの最新機能が強化されているほか、開発者向けにゲームの開発とデプロイの簡略化を支援する優れた新機能が追加されています。Amazon GameLift サービスのクールな機能のいくつかについて見てみましょう。

  • 複数エンジンのサポート: 当初、Amazon GameLift サービスは Amazon Lumberyard ゲームエンジンのみで使用できました。現在、このサービスは強化され、Unreal EngineUnity のような一般的なゲームエンジンをはじめ、カスタム C# と C++ ゲームエンジンと統合されます。
  • 新しいサーバー SDK 言語のサポート: より多くのお客様と開発者をサポートするため、このサービスでは C# と C++ で利用できる Amazon GameLift Server SDK が提供されます。これには、Amazon GameLift 用の Unreal Engine API と互換性のある、カスタマイズされたバージョンの C++ Server SDK である Unreal Engine プラグインが含まれています。
  • クライアント SDK 言語サポートの拡張: Amazon GameLift Client SDK は 多数の言語で提供されている AWS SDK にバンドルされました。これにより、ゲーム開発者は選択した言語で Amazon GameLift サービスが統合されたゲームクライアントを構築できます。
  • マッチメーキング: Amazon GameLift は世界中の利用可能なゲームサーバーを継続的にスキャンし、プレイヤーのリクエストにマッチングしてゲームに参加させます。低レイテンシーのゲームサーバーが利用できない場合は、プレイヤーの周囲にキャパシティーを自動的に追加するようサービスを設定できます。Amazon GameLift は新しいゲームが開始されるか新しいインスタンスが起動するまで待機中のプレイヤーのキューを維持してから、待機中のプレイヤーを最もレイテンシーが低いゲームに配置します。
  • プレイヤーデータの処理: ゲーム開発者はカスタムプレイヤー情報を保存し、ゲームサーバーに直接渡せるようになりました。これにより、ゲームサーバーまたは API を持つその他のゲームエンティティは、Amazon GameLift からプレイヤーデータを取得できます。
  • コンソールのサポート: Amazon GameLift は、XBox One および PS4 用に開発、作成されたゲームをサポートします。

Amazon GameLift はセッションベースのマルチプレイヤーゲームの作成に必要であった手間のかかるタスクを、ゼロからのインフラストラクチャの構築に関連する時間、コスト、リスクを減らしつつ、ゲームサーバーのデプロイ、スケーリング、維持のプロセスを簡略化することで実行します。Amazon GameLift を利用するゲームソリューションのリファレンスアーキテクチャを次に示します。

 

ゲームへの Amazon GameLift の統合
ゲームビルドへの Amazon GameLift の統合はいくつかの簡単なステップに分割できます。

  1. Amazon GameLift Server SDK を使用してゲームサーバープロジェクトを設定し、プロジェクトに通信コードを追加して、ゲームサーバーで Amazon GameLift のホスティングを準備します。
  2. ゲームデプロイの対象とした AWS リージョンに対してゲームサーバービルドをパッケージ化し、アップロードします。
  3. ゲームをホストするための複数のコンピューティングリソースを作成、構築します。
  4. AWS SDK と Amazon GameLift API を使用して Amazon GameLift によって維持されるゲームセッションに接続するようゲームクライアントを準備し、Amazon GameLift サービスへの呼び出しのゲームクライアント用のコードを追加して、プレイヤーのリージョンを識別します。
  5. Amazon GameLift でホストされたゲームセッションに接続し、ゲームセッションを作成中であることを確認して、Amazon GameLift の統合をテストします。

Unreal ゲームエンジンを使用して簡単なゲームサーバープロジェクトで Amazon GameLift Server SDK をセットアップして、これらのステップの実行を開始しましょう。Unreal Engine (UE) Epic の Unreal ゲームエンジンから開始します。分かりやすいように、オンラインマルチプレイヤー機能が組み込まれたサンプルの Shooter Game プロジェクトを作成し、コンピュータにローカルに保存します。

マルチプレイヤー Shooter Game のサンプルをダウンロードし、マシンでローカルに開いたので、C++ コードを操作して、Amazon GameLift サービスを UE オンラインサブシステムに追加し、オンラインゲームセッションを管理する必要があります。Shooter Game サンプルは Unreal Engine の Blueprints Visual Scripting システムを利用します。Blueprints システムは UE エディタのノードベースのインターフェイスに基づくゲームプレイスクリプティングシステムです。これにより、ゲーム設計者とコンテンツ作成者は UE エディタ内でゲームプレイ要素と機能を作成できます。私の目標は Amazon GameLift C++ SDK を使用して Amazon GameLift サービスをゲームに含め、ゲームコードを変更することなので、ゲームと結び付ける Visual Studio プロジェクトソリューションを作成し、Shooter Game のソースコードとバイナリをプロジェクトに関連付ける必要があります。これを達成するため、コンテキストメニューに移動して、[File] メニューオプションを選択します。メニューのドロップダウンで、[Generate Visual Studio Project Files] オプションを見つけて選択します。

プロジェクトが生成されたら、コンテキストメニューに戻って [File] を選択し、プロジェクトを開いてソースコードを表示するために [Open with Visual Studio] を選択します。

Amazon Game Lift サービスをゲームサービスとして Shooter Game に追加する準備として、またゲームセッションの管理のため、プロジェクトで OnlineSubSystem モジュールを有効にする必要があります。これを行うには、Visual Studio プロジェクトでゲームビルド設定ファイルを開きます。このゲームプロジェクトの名前は ShooterGame であるため、ビルドファイルの名前は ShooterGame.Build.cs になり、次に示すように Source/ShooterGame フォルダにあります。

ビルドファイルを開き、OnlineSubsystemNull モジュールの行のコメントを解除します。既にマルチプレイヤーオンラインシステムを利用しているサンプルを使用しているため、ビルドオプションは適切に設定され、コードは次のようになります。

public class ShooterGame : ModuleRules
{
	public ShooterGame(TargetInfo Target)
	{
		PrivateIncludePaths.AddRange(
			new string[] { 
				"ShooterGame/Classes/Player",
				"ShooterGame/Private",
				"ShooterGame/Private/UI",
				"ShooterGame/Private/UI/Menu",
				"ShooterGame/Private/UI/Style",
				"ShooterGame/Private/UI/Widgets",
            		}
		);
       PublicDependencyModuleNames.AddRange(
			new string[] {
				"Core",
				"CoreUObject",
				"Engine",
				"OnlineSubsystem",
				"OnlineSubsystemUtils",
				"AssetRegistry",
             			"AIModule",
				"GameplayTasks",
			}
		);
       PrivateDependencyModuleNames.AddRange(
			new string[] {
				"InputCore",
				"Slate",
				"SlateCore",
				"ShooterGameLoadingScreen",
				"Json"
			}
		);
		DynamicallyLoadedModuleNames.AddRange(
			new string[] {
				"OnlineSubsystemNull",
				"NetworkReplayStreaming",
				"NullNetworkReplayStreaming",
				"HttpNetworkReplayStreaming"
			}
		);
		PrivateIncludePathModuleNames.AddRange(
			new string[] {
				"NetworkReplayStreaming"
			}
		);
	}
}

これで Shooter Game プロジェクトを設定したので、Amazon GameLift SDK に再び注目しましょう。C++ SDK を Unreal Engine のプラグインとして利用したいので、このゲームエンジン用のバイナリを構築するコンパイルディレクティブを使用して SDK をコンパイルする必要があります。SDK ソースをダウンロードした状態で、オペレーティングシステムに基づいてソースから SDK をコンパイルできます。このプロジェクトには Windows マシンを使用しているため、次のステップを完了します。

  • コードのコンパイルから生成されたバイナリを保持する out ディレクトリを作成します。

mkdir out

  • 前に作成したディレクトリに移動します。

cd out

  • CMake を使用して、VS 2015 Win x64 のビルドシステムジェネレーターを指定し、UE コンパイルフラグを設定します。

cmake -DBUILD_FOR_UNREAL=1 -G “Visual Studio 14 2015 Win64” <ソースディレクトリ>

  • 選択したビルドシステム (このプロジェクトの場合は MS Build) を使用してバイナリを作成する C++ プロジェクトを構築します。

msbuild ALL_BUILD.vcxproj /p:Configuration=Release

ライブラリをコンパイルしたので、Amazon GameLift Unreal Engine プラグインを使用するために次のバイナリファイルが必要です。

Linux:

* out/prefix/lib/aws-cpp-sdk-gamelift-server.so

Windows:

* out\prefix\bin\aws-cpp-sdk-gamelift-server.dll

* out\prefix\lib\aws-cpp-sdk-gamelift-server.lib

次に示すように、私は Windows を使用しているため、コンパイルされた Amazon GameLift ライブラリ aws-cpp-sdk-gamelift-server.dll および aws-cpp-sdk-gamelift-server.lib はそれぞれ prefix\bin および prefix\lib フォルダにあります。

GameLiftSDK Unreal Engine プラグインフォルダにバイナリをコピーすると、Amazon GameLift プラグインフォルダが設定され、Unreal Engine ゲームプロジェクトに追加する準備が整います。これを踏まえて、Unreal Engine の ShooterGame プロジェクトに Amazon GameLift プラグインを追加します。Unreal Engine Editor を使用してプラグインを追加できますが、その代わりに、Visual Studio プロジェクトに留まり、ゲームディレクトリとプロジェクトファイルを更新してプラグインを追加します。

Windows エクスプローラーで、Plugins というフォルダを ShooterGame ディレクトリに追加し、準備した GameLiftServerSDK フォルダを、Unreal Engine のプラグインに関するドキュメントに示されているように、このディレクトリにコピーします。

ここで、ShooterGame.Build.cs ファイルを開きます。これはゲームの依存関係に関する情報を保持する C# ファイルです。

ファイル内で次のコードを追加します。

PublicDependencyModuleNames.AddRange(
            new string[] {
                "Core",
                "CoreUObject",
                "Engine",
                "InputCore",
                "GameLiftServerSDK"
            }
       );

これまでに行った変更とすべてが同期されていることを確認するため、Visual Studio を閉じ、UE Editor に戻って [Refresh Visual Studio Project] を選択します。

完了したら、[Open Visual Studio] を選択します。ShooterGame ディレクトリに追加した Plugins フォルダがプロジェクトに含まれていて、Solution Explorer で表示できます。

次に、ソリューション全体を再構築して、Amazon GameLift SDK バイナリをプロジェクトに統合します。

UE Editor に戻り、ツールバーの [Build] を選択して、Amazon GameLift プラグインの側面が ShooterGame に含まれていることを確認します。コンパイルが完了したら、[Settings] ツールバーを簡単に確認します。[Plugins] オプションには Amazon GameLift プラグインが追加されていて、プロジェクトで認識されていることがわかります。[Enabled] チェックボックスを選択します。これにより、UE Editor の再起動が求められます。[Restart Now] を選択し、Unreal Engine がゲームコードファイルを再構築できるようにします。

ビルドが完了すると、エディタが再起動し、ShooterGame がもう一度開かれます。

これで ShooterGame プロジェクトで Amazon GameLift SDK の使用に関する設定が完了しました。Unreal エディタを開いた状態で、[Open Visual Studio] メニューオプションに移動し、ShooterGame コードに戻ります。これにより、Visual Studio およびゲームコードが開きます。Visual Studio を開いた状態で、ShooterGameMode.cpp ファイルに移動し、コードを追加して Amazon GameLift SDK を初期化します。Shooter Game プロジェクト内で Amazon GameLift に正しくコードを追加するために実行する必要がある主要なことは、次のとおりです。

  1. フラグ WITH_GAMELIFT=1 を使用してプリプロセッサ条件内で Amazon GameLift コードを囲みます
  2. 対象のサーバー OS (Linux など) 用に、Unreal Engine で専用サーバーを構築します
  3. ビルドの対象がゲームサーバータイプであることを確認します (Type == TargetRules.TargetType.Server)

Unreal Engine プロジェクトで Amazon GameLift を追加するために必要なコードの例は、こちらのドキュメントに記載されています。さらに、Unreal Engine wiki で提供されている Windows および Linux 向けの専用サーバーガイドに従って、Unreal Engine の専用サーバーを構築する方法を参照できます。これらの資料を利用すると、Amazon GameLift をゲームプロジェクトに首尾よく統合できます。Unreal Engine ゲームエンジンへの Amazon GameLift SDK の組み込みについて簡単に説明しましたが、Amazon GameLift SDK を Unity など C# エンジンに追加するオプションもあることを忘れないでください。Amazon GameLift Server SDK をダウンロードし、.Net framework 3.5 ソリューションをコンパイルすることで、GameLiftServerSDKNet35.sln になります。GameLiftServerSDKNet35.sln ソリューションを使用すると、Amazon GameLift ライブラリを Unity3D プロジェクトに追加することができます。Amazon GameLift C# Server SDK プラグインのセットアップと使用の詳細については、Amazon GameLift SDK ドキュメント「Unity での C# サーバー SDK の使用」を参照してください。

要約
Amazon GameLift マネージド型サービスに追加された新しい側面の 1 つのみを説明しましたが、このサービスは開発者やゲームスタジオに対してさらに多くの機能を提供しています。Amazon GameLift は、DDoS 攻撃からゲームを防御しながら、インフラストラクチャの管理、キャパシティーのスケーリング、利用可能なゲームセッションへのプレイヤーのマッチングを簡単にして、分散型ゲームを構築できます。

Amazon GameLift サービスの詳細については、Amazon GameLift のドキュメントと Amazon GameLift 開発者ガイドを参照してください。また、Amazon GameDev チュートリアルページの Amazon GameLift チュートリアルを確認して、Amazon GameLift サービスを使用したゲーム開発を本格的に開始することができます。どうぞゲームをお楽しみください。

Tara

Amazon Rekognitionを使ってMacOS Finderのタグ機能を更に良いものにしよう

こちらは、AWSのGlobal Startup EvangelistであるMackenzie Kosut(@mkosut)によってAWS Startups Blogに投稿された「Using Amazon Rekognition to enhance MacOS Finder Tags」の翻訳記事です。


日曜の朝、私はラップトップにある何百枚もの写真が保存されている大きなフォルダを眺めていました。サムネイルは素晴らしいのですが、私が本当にやりたかったことは、簡単にそしてクイックに”崖”の写真を探し当てることでした。

OS X Mavericksからタグ機能が使えるようになり、Finderウインドウでタグ付けされたファイルを探せるようになっています。そこで、私はラップトップからAmazon Rekognitionに写真を送信し、それぞれの写真についてAmazon RekognitionのDeep Learningベースの画像認識を行い、そして、識別情報をタグとしてファイルに登録し、Finderでそのファイルを開けるようにする、という一連の処理に関してどの程度の手間がかかるのか知りたいと思っていました。

これが実現できると、FinderもしくはSpotlight(MacOSの検索機能)において、Tag:<term>という形で検索できるようになります。例えば、全ての猫(cat)の写真を引き当てたい場合は Tag:Cat と入力することで結果を得ることが出来る、というものです。

writexattrsファンクションのコードスニペットをオンラインで見つけた後、そうこうするうちに、Amazon Rekognitionに写真を送り、Tagの結果を得て、それらをファイルに登録することが出来てしまいました。約30分の間に50行ほどのコードを書いて、それが実際に動作するプロトタイプになりました。

コードは https://github.com/mkosut/rekognition_osx_tagfile にありますので、是非ご覧になさってください。

多数の写真がある大きなフォルダーについても正しく動作しました。そして、パフォーマンス向上のため、アップロードの前にイメージのリサイズを行い、プロセスをマルチスレッドで行えるようなpull requestをチームの中のメンバーが送ってくれました。

私が本当に欲しかったものは、画像がフォルダに追加された時に自動でタグ付けされる、というものでした。私はそのためにMacOS Automatorを活用しました。Automatorでは使い勝手の良い簡単なインターフェースを通じてフォルダーのアクティビティをウォッチすることができ、新しいファイルが書き込まれたらアクションを走らせることができます。これはAmazon S3にファイルのファイルが変更された時にAWS Lambdaの処理をいつでも自動的に稼働させるものと似ていると言えるでしょう。

このワークフローは”TagMe”フォルダーに新しいファイルが書き込まれるのを待ち受け、それらを rek_osx_tagfile.py スクリプトにファイル名をパラメーターとして渡して起動します。

それでは最終テストです:

成功しました!

このhackを通して私は大きな気付きを得ました。それは、AWSはどんなことにも活用できるケーパビリティを持っているということです。ここには非力な1台のラップトップしかありませんが、私はAmazon Rekognitionの巨大なDeep Learning基盤を用いることで大量の写真の解析をすることができましたし、何より少ないコードでそれを実現できました!

 

翻訳:篠原英治(原文:「Using Amazon Rekognition to enhance MacOS Finder Tags」 – https://aws.amazon.com/blogs/startups/using-amazon-rekognition-to-enhance-macos-finder-tags/

Amazon WorkDocs の更新 – コメントやレビュー機能の強化と新しいアクティビティフィード

以前にも触れましたが、Amazon では自社のシャンパンを好んで飲むようにしています。つまり、独自で開発したサービス、ツール、アプリケーションを仕事の一部として使用し、その上で改善に役立ちそうなアイデアや予想どおりに機能していないものについて開発チームにフィードバックを提供するようにしています。Amazon WorkDocs (旧名: Zocalo) を初めて紹介したのは 2014 年の中頃ですが、私はそれ以来ずっとこのサービスを使用しています (忙しい時は下書きの段階にあるブログが同時に 7 件~8 件あることも稀ではありません)。新しいブログ投稿の下書き (通常 PDF 形式) を WorkDocs にアップロードし、プロダクトマネージャー、プロダクトマーケティングマネージャー、指定されているその他のレビュー担当者と共有します。レビュー後にフィードバックを追加してもらい、下書きを更新して次のフィードバックを待ちます。このプロセスを何度か繰り返した後に下書きが完了し、ブログ投稿の許可を待ちます。このレビュープロセスには開発者、シニアマネジメントなども含まれます。私はドキュメントを共有してフィードバックを待つだけです。できる限り早急にフィードバック (いくつもの提案と場合によっては質問) をすべて読みプロセスし、見落としがないか確認するのが私の仕事です。そこで、今回はこれまで以上に WorkDocs を便利にする最新の機能強化についてご紹介します。コメント機能やレビュー機能の他にアクティビティフィードも追加しました。

コメント機能の強化
レビュープロセスを行っている間に追加されたコメントからディスカッションが始まる場合もあります。特定の機能やイメージが適切であるかどうか検討が必要な場合もあります。会話を簡単に始めたり続行できるようにするため、WorkDocs がスレッドで構成したコメントをサポートできるようになりました。[Reply] をクリックしてコメントに返信するだけです。

次のように表示されます。

[Private] をクリックすると、これにアクセスできるのは最初のコメントを書いたユーザーのみになります。メッセージを分かりやすくするため、コメントでシンプルな形式 (太字、斜体、取り消し線) を使用することもできます。詳しくはこちらをご覧ください。

使用例をご覧ください。

[?] をクリックすると、形式に関する簡単なガイドが表示されます。

コメントのプロセスが完了したら、クリック 1 回でフィードバック機能を無効にすることができます。

詳細については 「フィードバックを追加するには」を「WorkDocs ユーザーガイド」でご覧ください。

レビュー機能の強化
コメントが増えるにつれて、場合によってはレビュー担当者たちに特に注目して欲しいコメントもあると思います。そのような時は、コメント内で @ を入力しポップアップメニューからユーザー名を選択します。

ユーザーにはフィードバックが必要なことをメールでお知らせします。これまでは、レビュー担当になる可能性があるユーザーに WorkDocs ドキュメントの URL が渡っても、そのドキュメントへのアクセスは付与されていませんでした。今後は、そうしたユーザーでも次のようなドキュメントへのアクセスをリクエストできるようになりました。

リクエストはメール経由でドキュメントの所有者から承認を受けるために転送されます。同様に、読み取り専用のアクセス権を許可されていたユーザーも寄稿者レベルのアクセス権をリクエストできるようになりました。

繰り返しますが、リクエストはメール経由でそのドキュメントの所有者から承認を受けるために転送されます。

 

アクティビティフィード
常時、複数のブログ投稿がレビュープロセスにあるので、これらを上手に整理することはなかなかのチャレンジです。全体図をより分かりやすく提供するため、WorkDocs にアクティビティフィードが追加されました。フィードを見れば、共有しているドキュメントで何が起きているのかが分かります。ファイルやフォルダの作成、変更、削除や追加されたコメントを確認できます。さらに誰が変更を追加したのか、そして変更した日時を確認することもできます。

検索用語を入力してフィードに何を表示するか管理できます。

アクティビティタイプや日付別にフィルターに掛けることもできます。

 

今すぐ利用可能
これらの機能は今すぐご利用いただけます。

Jeff;

Amazon Elasticsearch Service が Elasticsearch 5.1 をサポート

Amazon Elasticsearch Service は、オープンソース検索および分析エンジンである Elasticsearch を容易にデプロイ、運用、拡張できるようにするマネージド型サービスです。このたび Amazon Elasticsearch Service で Elasticsearch 5.1 および Kibana 5.1 がサポートされるようになったことを、ここにお知らせいたします。Elasticsearch 5 は非常に多くの新機能と機能拡張を備えており、Amazon Elasticsearch Service をご利用のお客様はそれらを活用いただけるようになりました。今回の Elasticsearch 5 のリリースには、次のような内容が含まれています。

  • インデックス作成のパフォーマンス: ロックの実装の更新および非同期のトランザクションログ FSYNC による、インデックス作成のスループットの向上
  • 取り込みパイプライン: 受信データは一連の取り込みプロセッサを適用するパイプラインに送信できます。これにより検索インデックスに必要なデータに正確に変換できます。単純な付加アプリケーションから複雑な正規表現アプリケーションまで、20 個のプロセッサが含まれています
  • Painless スクリプティング: Amazon Elasticsearch Service は Elasticsearch 5 のための新しい安全でパフォーマンスに優れたスクリプト言語である、Painless をサポートします。スクリプト言語を使用すると、検索結果の優先順位を変更したり、クエリでインデックスフィールドを削除したり、検索結果を修正して特定のフィールドを戻したりすることができます。
  • 新しいデータ構造: 新しいデータ型である Lucene 6 データ構造をサポートし、半精度浮動小数点、テキスト、キーワード、さらにピリオドが含まれるフィールド名を完全にサポートします
  • 検索と集計: リファクタリング検索 API、BM25 関連性計算、Instant Aggregations、ヒストグラム集計と用語集計の機能強化、再設計されたパーコレーターと完了サジェスタ
  • ユーザーエクスペリエンス: 厳密な設定、本文とクエリ文字列パラメーターの検証、インデックス管理の向上、デフォルトで廃止予定のログを記録、新しい共有割り当て API、ロールオーバーと圧縮 API のための新しいインデックス効率パターン
  • Java REST クライアント: Java 7 で稼働してノード障害時に再試行 (またはラウンドロビン、スニッフィング、要求のログ記録) を処理するシンプルな HTTP/REST Java クライアント
  • その他の向上: 遅延ユニキャストのホスト DNS ルックアップ、再インデックス作成の自動並列タスク、update-by-query、delete-by-query、タスク管理 API による検索のキャンセル

Elasticsearch 5 による強力な新機能や機能強化により、サービスをより迅速に、より容易に提供することができ、さらにセキュリティの強化を図ることができます。マネージド型サービスである Amazon Elasticsearch Service を使うと、お客様は Elasticsearch による次のような機能を活用して、ソリューションを構築、開発、デプロイすることができます。

  • 複数のインスタンスタイプを設定
  • データストレージに Amazon EBS ボリュームを使用
  • 専用マスターノードによるクラスターの安定性の向上
  • ゾーン対応 – 同じリージョン内の 2 つのアベイラビリティーゾーンにまたがるクラスターノード割り当て
  • AWS Identity and Access Management (IAM) によるアクセスコントロールとセキュリティ
  • リソース用にさまざまな地理的場所やリージョンを活用
  • Amazon Elasticsearch ドメインのスナップショットによるレプリケーション、バックアップ、リストア
  • Amazon CloudWatch との統合による Amazon Elasticsearch ドメインメトリクスのモニタリング
  • AWS CloudTrail との統合による設定の監査
  • Kinesis Firehose および DynamoDB などの他の AWS のサービスとの統合による、リアルタイムストリーミングデータの Amazon Elasticsearch Service への読み込み

Amazon Elasticsearch Service では、ダウンタイムなしで動的な変更を行うことができます。インスタンスの追加、インスタンスの削除、インスタンスのサイズの変更、ストレージ設定の変更、その他の変更を動的に行うことができますい。上記の機能のいくつかについて、その機能を具体例でご紹介します。先日の IT/Dev カンファレンスでは、Express.js、AWS Lambda、Amazon DynamoDB、および Amazon S3 を使用して、サーバレスで従業員オンボーディングシステムを構築する方法の説明を、プレゼンテーションさせていただきました。このデモでは、架空のオンボーディングプロセス用の従業員に関する人事データを収集して、DynamoDB に保存しました。収集された従業員データを、会社の人事部門が必要に応じて検索、照会、分析するシナリオを考えてみます。オンボーディングシステムを容易に拡張して、従業員テーブルが DynamoDB Streams を使用して Lambda を起動するようにし、必要な従業員の属性を Amazon Elasticsearch Service に保存することができます。この結果、次のようなソリューションアーキテクチャとなります。

従業員レコードが入力されてデータベースに保存されるたびに、従業員データを Amazon Elasticseach Service に動的に保存してインデックスを作成する方法のみに焦点を当てます。前述の既存のオンボーディングソリューションにこの拡張機能を追加するには、以下の詳細なクラウドアーキテクチャ図に示すように、ソリューションを実装します。

従業員の Amazon Elasticsearch Service へのロードプロセスを実装する方法を見てみましょう。これは上の図に示されている最初のプロセスフローです。Amazon Elasticsearch Service: ドメイン作成 AWS コンソールにアクセスして、Elasticsearch 5 が実行されている Amazon Elasticsearch Service を確認しましょう。ご想像どおり、AWS コンソールのホームから [分析] グループの [Elasticsearch Service] を選択します。

Elasticsearch ソリューションを作成するための最初のステップは、ドメインの作成です。お気付きのとおり、Amazon Elasticsearch Service ドメインの作成時に Elasticsearch 5.1 バージョンを選択できるようになりました。今日の本題は Elasticsearch 5 のサポート開始ですので、Amazon Elasticsearch Service でのドメイン作成にあたり、もちろん 5.1 Elasticsearch エンジンのバージョンを選択します。


[Next] をクリックし、インスタンスとストレージの設定を構成して、Elasticsearch ドメインを設定します。クラスターのインスタンスタイプとインスタンス数は、アプリケーションの可用性、ネットワークボリューム、およびデータのニーズに基づいて決定する必要があります。データの不整合や Elasticsearch のスプリットブレインの問題を回避するために、複数のインスタンスを選択することが推奨されるベストプラクティスです。そこで、今回はクラスター用に 2 つのインスタンス/データノードを選択し、EBS をストレージデバイスとして設定します。

具体的なアプリケーションに必要なインスタンスの数を理解するには、AWS データベースブログの「Get Started with Amazon Elasticsearch Service: How Many Data Instances Do I Need (Amazon Elasticsearch Service をはじめよう: 必要なインスタンス数の算出方法)」の記事を参照してください。あと必要なのは、アクセスポリシーを設定してサービスをデプロイするだけです。サービスを作成すると、ドメインが初期化され、デプロイされます。

これで Elasticsearch Service を実行することができました。次は、データを入力するメカニズムが必要です。DynamoDB Streams を使用して、Amazon Elasticsearch Service への従業員データの動的なデータロードプロセスを実装します。Amazon DynamoDB: テーブルとストリーム DynamoDB コンソールに着手する前に、まずは基本を簡単に確認しましょう。 Amazon DynamoDB はスケーラブルな分散 NoSQL データベースサービスです。DynamoDB Streams は、すべての CRUD オペレーションの順序付けられた時間ベースのシーケンスを DynamoDB テーブル内の項目に提供します。各ストリームレコードには、テーブル内の個々の項目のプライマリ属性の変更に関する情報が含まれています。ストリームは非同期で実行され、実質的にリアルタイムでストリームレコードを書き込むことができます。さらに、ストリームはテーブルの作成時に有効にでき、また既存のテーブルで有効にして変更することができます。DynamoDB Streams の詳細については、「DynamoDB 開発者ガイド」を参照してください。それでは DynamoDB コンソールから、OnboardingEmployeeData デーブルを確認しましょう。

このテーブルには、プライマリパーティションキー UserID があり、これは文字列データ型です。さらにプライマリソートキー Username があり、これも文字列データ型です。ここでは UserID を Elasticsearch のドキュメント ID として使用します。さらにこのテーブルではストリームが有効で、ストリームの表示タイプは New image です。表示タイプが New image に設定されたストリームには、更新された後に項目レコード全体を表示するストリームレコードがあります。ストリームが、変更前のデータ項目を提供するレコードを表示するようにすることもできます。また項目のキー属性のみを提供したり、古い項目と新しい項目の情報を提供したりすることもできます。AWS CLI を使用して DynamoDB テーブルを作成する場合、取得するキー情報は [Stream Details] セクションの下に表示される 最新のストリーム ARN です。DynamoDB ストリームには一意の ARN 識別子があります。これは DynamoDB テーブルの ARN の外にあります。ストリーム ARN は、ストリームと Lambda 関数の間のアクセス権限の IAM ポリシーを作成するために必要です。

IAM ポリシー あらゆるサービスの実装で第一に重要なことは、適切なアクセス権限を設定することです。このため、まずは IAM コンソールを使って、DynamoDB と Elasticsearch にアクセス権限を設定する、Lambda 関数のロールとポリシーを作成します。まず、DynamoDB ストリームを使用した Lambda の実行のための既存の管理ポリシーに基づくポリシーを作成します。

すると次にポリシーの確認画面に移ります。ここでは選択された管理ポリシーの詳細が表示されます。ここでは、このポリシーの名前を Onboarding-LambdaDynamoDB-toElasticsearch として、ソリューション用にポリシーのカスタマイズを行います。現在のポリシーでは、すべてのストリームがアクセス可能であることに注意します。推奨されるベストプラクティスは、最新のストリーム ARN を追加して、このポリシーで特定の DynamoDB ストリームのみがアクセスできるようにすることです。ポリシーを変更して、DynamoDB テーブル OnboardingEmployeeDataARN を追加し、ポリシーを検証します。変更されたポリシーは次のようになります。

あとは、Amazon Elasticsearch Service のアクセス権限をポリシーに追加するだけです。Amazon Elasticsearch Service のアクセス権限のコアポリシーは次のとおりです。

このポリシーを使って、特定の Elasticsearch ドメインの ARN を、ポリシーのリソースとして追加します。これにより、ポリシーのセキュリティのベストプラクティスである、最小権限の原則を適用したポリシーを活用することができます。次のように Amazon Elasticsearch Service ドメインを追加して、ポリシーを検証して保存します。

カスタムポリシーを作成する最も望ましい方法は、IAM Policy Simulator を使用するか、またはサービスドキュメントの AWS のサービスのアクセス権限の例を参照することです。AWS のサービスのサブセットのポリシーの例については、こちらを参照することもできます。最小権限の原則によるセキュリティのベストプラクティスを適用して、必要な ES のアクセス権限のみを追加してください。上記は単なる一例です。アクセスを許可するために Lambda 関数が使用するロールを作成し、そのロールに前述のポリシーをアタッチします。

AWS Lambda: DynamoDB がトリガーする Lambda 関数 AWS Lambda は、アマゾン ウェブ サービスのサーバーレスコンピューティングサービスの中心となるものです。Lambda を使うと、サポートされた言語を使って、事実上あらゆる種類のアプリケーションやバックエンドサービスのコードを作成して実行できます。Lambda は、AWS のサービスまたは HTTP リクエストからのイベントに対応して、コードをトリガーします。Lambda はワークロードに基づいて動的にスケールします。コードの実行に対してのみ料金を支払います。DynamoDB ストリームが Lambda 関数をトリガーし、それによりインデックスが作成され、データが Elasticsearch に送信されます。もう 1 つの方法は、DynamoDB の Logstash プラグインを使用することです。ただし、Logstash プロセッサのいくつかは Elasticsearch 5.1 コアに組み込まれ、さらにパフォーマンスの最適化が向上されているため、今回は Lambda を使用して DynamoDB ストリームを処理し、Amazon Elasticsearch Service にデータをロードすることにします。では AWS Lambda コンソールを使って、Amazon Elasticsearch Service に従業員データをロードするための Lambda 関数を作成しましょう。コンソールでブランク関数設計図を選択して、新しい Lambda 関数を作成します。次に [Configure Trigger] ページに移ります。トリガーページで、Lambda をトリガーする AWS のサービスとして DynamoDB を選択し、トリガー関連オプションとして次のように入力します。

  • テーブル: OnboardingEmployeeData
  • バッチサイズ: 100 (デフォルト)
  • 開始位置: 水平トリム

[Next] をクリックすると、関数の設定画面に移動します。関数の名前を ESEmployeeLoad とし、この関数を Node.4.3 で作成します。

Lambda 関数のコードは次のとおりです。

var AWS = require('aws-sdk');
var path = require('path');

//すべての ElasticSearch ドメイン情報のオブジェクト
var esDomain = {
    region: process.env.RegionForES,
    endpoint: process.env.EndpointForES,
    index: process.env.IndexForES,
    doctype: 'onboardingrecords'
};
//作成された ES ドメインエンドポイントからの AWS エンドポイント
var endpoint = new AWS.Endpoint(esDomain.endpoint);
//AWS 認証情報は環境から取得される
var creds = new AWS.EnvironmentCredentials('AWS');

console.log('Loading function');
exports.handler = (event, context, callback) => {
    //console.log('Received event:', JSON.stringify(event, null, 2));
    console.log(JSON.stringify(esDomain));
    
    event.Records.forEach((record) => {
        console.log(record.eventID);
        console.log(record.eventName);
        console.log('DynamoDB Record: %j', record.dynamodb);
       
        var dbRecord = JSON.stringify(record.dynamodb);
        postToES(dbRecord, context, callback);
    });
};

function postToES(doc, context, lambdaCallback) {
    var req = new AWS.HttpRequest(endpoint);

    req.method = 'POST';
    req.path = path.join('/', esDomain.index, esDomain.doctype);
    req.region = esDomain.region;
    req.headers['presigned-expires'] = false;
    req.headers['Host'] = endpoint.host;
    req.body = doc;

    var signer = new AWS.Signers.V4(req , 'es');  // es: サービスコード
    signer.addAuthorization(creds, new Date());

    var send = new AWS.NodeHttpClient();
    send.handleRequest(req, null, function(httpResp) {
        var respBody = '';
        httpResp.on('data', function (chunk) {
            respBody += chunk;
        });
        httpResp.on('end', function (chunk) {
            console.log('Response: ' + respBody);
            lambdaCallback(null,'Lambda added document ' + doc);
        });
    }, function(err) {
        console.log('Error: ' + err);
        lambdaCallback('Lambda failed with error ' + err);
    });
}

Lambda 関数の環境変数は次のとおりです。

既存のロールのオプションで ESOnboardingSystem を選択します。これは先に作成した IAM ロールです。

Lambda 関数のための IAM ロールのアクセス権限を完成したら、Lambda 関数の詳細を確認し、ESEmployeeLoad 関数の作成を完了します。

Elasticsearch との通信を行う Lambda 関数の構築プロセスは、これで完了です。では、データベースへのデータ変更のシミュレーションを行って、関数のテストを行いましょう。

関数 ESEmployeeLoad は、オンボーディングシステムのデータベースでのデータの変更により実行されます。また、CloudWatch ログを確認することにより、Lambda 関数の Elasticsearch への処理を確認できます。さらに Lambda 関数を変更して新機能を利用したり、直接 Elasticsearch を使って新しい取り込みモードを利用することもできます。たとえば、従業員レコードドキュメントのパイプラインを実装することができます。

この関数を複製して、従業員レコードに合わせてバッジを更新する処理や、従業員データに対するその他のプリプロセッサを活用したりすることができます。たとえば、Elasticsearch ドキュメントのデータパラメーターに基づいてデータを検索する場合、検索 API を使用してデータセットからレコードを取得できます。

可能性は無限です。データのニーズに応じて創造性を発揮しながら、優れたパフォーマンスを確保できます。Amazon Elasticsearch Service: Kibana 5.1 Elasticsearch 5.1 を使用しているすべての Amazon Elasticsearch Service ドメインでは、オープンソースの可視化ツールの最新バージョンである Kibana 5.1 が備えられています。可視化と分析のための補完プラットフォームである Kibana も、Kibana 5.1 リリースで機能強化されました。Kibana を活用すると、さまざまなグラフ、テーブル、マップを使用して、Elasticsearch データの表示、検索、操作を行うことができます。さらに、Kibana は大量データの高度なデータ分析を実行できます。Kibana リリースの主な機能強化は次のとおりです。

  • 可視化ツールの新しいデザイン: カラースキームの更新と表示画面活用の最大化
  • Timelion: 時間ベースのクエリ DSL による可視化ツール
  • コンソール: 従来 Sense と呼ばれていた機能がコア機能の一部となりました。以前と同様の設定を使って、Elasticsearch へのフリーフォームのリクエストを行うことができます
  • フィールドスクリプト言語: Elasticsearch クラスターで新しいスクリプト言語 Painless を使うことが可能
  • タグクラウドの可視化: 5.1 では、データの重要度による単語ベースのグラフィカルビューが追加されました
  • グラフの拡張: 前回削除されたグラフが復活し、さらに X-Pack の高度なビューが追加されました
  • Profiler の UI: ツリービューによる Profile API の拡張を提供
  • レンダリングパフォーマンスの向上: パフォーマンスを向上させ、CPU 負荷を低減

まとめ ご覧いただいたように、このリリースでは Elasticsearch ソリューションの構築に役立つ、広範な機能強化や新機能を備えています。Amazon Elasticsearch Service では新たに、15 個の Elasticsearch API と 6 つのプラグインをサポートします。Amazon Elasticsearch Service は Elasticsearch 5.1 の次のオペレーションをサポートします。

Elasticsearch でサポートされるオペレーションの詳細については、「Amazon Elasticsearch 開発者ガイド」を参照してください。また Amazon Elasticsearch Service のウェブサイトを活用したり、AWS マネジメントコンソールにサインインして開始することもできます。- Tara

 

Amazon EC2 Systems Manager を使用して AMI メンテナンスとパッチ適用を合理化 | 自動化

EC2 シニアプロダクトマネージャーの Taylor Anderson が自動化を利用して AMI メンテナンスとパッチ適用を合理化する方法についてご説明します。-Ana


去年 12 月の re:Invent でリリースした Amazon EC2 Systems Manager では、ソフトウェアインベントリの収集や OS パッチの適用、システムイメージの作成そして Windows や Linux のオペレーティングシステム設定などのプロセスを自動化することができます。こうした機能は自動設定や継続的に行う大規模なシステム管理を自動化し、Amazon EC2 やオンプレミスで実行しているインスタンスのソフトウェアコンプライアンスを維持することができます。Systems Manager には自動化の機能が含まれています。パッチの適用やエージェントの更新、Amazon Machine Image (AMI) にアプリケーションを組み込む場合に、この機能を使用することができます。自動化を使用することで、イメージの更新を手動で行うための時間や労力を省くことができます。代わりに、合理化し繰り返し可能で監査可能なプロセスを通じて AMI を構築することができます。先日、AWS は自動化に関する公開ドキュメントを初めてリリースしました。詳しくは AWS-UpdateLinuxAmi をご覧ください。

このドキュメントは Ubuntu、CentOS、RHEL、Amazon Linux AMI のパッチ適用を自動化できるようしたり、その他のサイト固有のパッケージと設定のインストールも自動化します。さらに、自動化ドキュメントを最初に書く必要を排除することで自動化を取り入れやすくしています。 AWS-UpdateLinuxAmi は、ご自分の自動化ワークフローを構築する場合にテンプレートとして使用することもできます。Windows ユーザーを対象にした、今後公開予定の AWS-UpdateWindowsAmi ドキュメントはこれと同等の内容を提供します。AWS-UpdateLinuxAmi は次のワークフローを自動化します。

  1. ソース Linux AMI から一時 EC2 インスタンスを起動
  2. インスタンスのアップデート
    • インスタンスでユーザー提供の更新前のフックを起動
    • 可能な場合にインスタンスの AWS ツールやエージェントを更新
    • ネイティブパッケージマネージャを使用してインスタンスのディストリビューションパッケージを更新
    • インスタンスでユーザー提供の更新後のフックを起動 (オプション)
  3. 一時インスタンスを停止
  4. 停止したインスタンスから新しい AMI を作成
  5. インスタンスを終了

警告: 実行中のインスタンスから AMI を作成すると、インスタンスの認証情報、社外秘情報、その他の機密情報が新しいイメージに記録される可能性があります。この方法で作成した AMI を管理する場合は十分な注意が必要です。

自動化のロールおよびアクセス権限の設定

過去に自動化を使用したことがない場合は、IAM ロールとアクセス権限を設定してください。これには自動化のサービス作成、passrole を指定してユーザーがサービスロールを提供できるように承認したり、インスタンスロールを作成して System Manager でインスタンス管理を有効にすることも含まれています。詳細については「自動化用にアクセスを設定する」を参照してください。

自動化を実行

      1. EC2 コンソールで [Systems Manager Services] > [Automations] を選択します。
      2. [Run automation document] を選択します。
      3. [Document name] で [AWS-UpdateLinuxAmi] を選択します。
      4. ドキュメントの最新バージョンを選択します。
      5. SourceAmiId に Linux AMI の ID を入力して更新します。
      6. InstanceIamRole に、インスタンスを管理するために System Manager を有効にして作成したインスタンスロール名を入力します (AmazonEC2RoleforSSM 管理ポリシーを含んでいるもの)。詳細については「自動化用にアクセスを設定する」を参照してください。
      7. [AutomationAssumeRole] に、自動化用に作成したサービスロールの ARN を入力します。詳細については「自動化用にアクセスを設定する」を参照してください。
      8. [Run Automation] を選択します。
      9. [Automation Steps] タブで進捗状況を監視し、ステップレベル出力を確認します。

実行が完了したら [Description] を選択してワークフローが返した出力を確認します。この例では AWS-UpdateLinuxAmi が新しい AMI ID を返しています。次に [Images] > [AMIs] を選択して新しい AMI を確認します。

自動化の使用に追加料金はかかりませんが、ワークフローで作成したリソースにはわずかな料金が発生します。「インスタンス削除」のステップに行く前に AWS-UpdateLinuxAmi を終了すると、ワークフローが作成した一時インスタンスは終了します。上記ステップの CLI チュートリアルについては「自動化 CLI チュートリアル: Linux AMI のパッチ適用」をご覧ください。

まとめ

AWS-UpdateLinuxAmi を問題なく実行できたら、サービスやインスタンスロールのデフォルト値を作成することをおすすめします。AWS-UpdateLinuxAmi をベースに、ご自分の自動化ドキュメントを作成してワークフローをカスタマイズすることができます。詳細については「 自動化ドキュメントの作成」をご覧ください。ドキュメント作成が完了したら追加ステップを書いてワークフローに足すことができます。ステップ例をご覧ください。

      • 新しい AMI ID で Auto Scaling を更新 (aws:invokeLambdaFunction アクションタイプ)
      • 新しい AMI の暗号化されたコピーを作成 (aws:encrypedCopy アクションタイプ)
      • RunPowerShellScript で Run Command を使用して新しい AMI を検証 (aws:runCommand アクションタイプ)

自動化はアプリケーションの組み込みに使う CI/CD パイプラインにとって大きな強化点となります。また、Jenkins で CLI 構築ステップとして呼び出すこともできます。こうした例の詳細については、自動化の技術文書を必ずご覧ください。

自動化、Amazon EC2 Systems Manager、Amazon CloudFormation、AWS Config、AWS OpsWorks やその他の管理サービスの更新については、新しい管理ツールのブログをフォローしてください。

EC2 リザーブドインスタンスの新たなインスタンスサイズの柔軟性

リザーブドインスタンスは AWS のお客様がご利用されている EC2 の使用量に対し、大幅な割引を提供します (オンデマンドの料金に比べ最大 75% の割引)。また、特定のアベイラビリティーゾーン (AZ) で使用する RI を購入される際のキャパシティー予約においても同様です。去年後半には、リージョン内の AZ すべてを対象に割引を適用するリージョン RI をリリースし、今まで以上にリザーブドインスタンスの柔軟性を高めました。また、リザーブドインスタンスに関連付けられたインスタンスファミリーやその他のパラメーターを変更できるようにするコンバーティブル RI も提供しました。どちらのタイプの RI も管理に掛かるコストを削減し、追加オプションを提供します。リージョン RI を使用すると、RI 割引の対象になる AZ で起動することを心配せずにインスタンスをスタートできます。コンバーティブル RI を使用する場合、時間が経過するに連れて選択するインスタンスタイプやサイズが変わっても、RI が使用量に適しているか確認することができます。

インスタンスサイズの柔軟性
3 月 1 日より、すでにご利用されているリージョン RI の柔軟性が今まで以上に高まります。一括請求により、複数のアカウントで使用している場合でも、共有テナンシーを持つすべての Linux/UNIX RI をインスタンスファミリーと AWS リージョン内のあらゆるサイズのインスタンスに適用できるようになりました。これにより、RI の管理時間を節約したり、コンピューティングリソースをよりクリエイティブで革新的に使用できるようになります。新しい RI や既存の RI のサイズはインスタンスサイズに基づいた正規化係数により決定されています。

インスタンスサイズ 正規化係数
nano 0.25
micro 0.5
small 1
medium 2
large 4
xlarge 8
2xlarge 16
4xlarge 32
8xlarge 64
10xlarge 80
32xlarge 256

c4.8xlarge の RI をすでに所有しているとします。この RI はそのリージョン内で共有テナンシーを使用する Linux/UNIX C4 インスタンスで適用されるようになりました。例については次をご覧ください。

  • c4.8xlarge インスタンス 1 件
  • c4.4xlarge インスタンス 2 件
  • c4.2xlarge インスタンス 4 件
  • c4.large インスタンス 16 件

また、c4.4xlarge インスタンス 1 件と c4.large インスタンス 8 件といった他の組み合わせも含みます。RI が実行中のインスタンスよりも小さな場合は、オンデマンド料金の日割り計算で余分な容量のコストが請求されます。つまり c4.4xlarge の RI を購入し、大抵の場合そのインスタンスを使用していても、時々 c4.8xlarge インスタンスにスケールアップすることができます。大きいインスタンスには時間単位でオンデマンド料金の半分が請求されます (AWS は可能な限りコストを抑えた状態でお客様がコンピューティング能力にアクセスできるようにすることを目的としています)。大きなインスタンスの RI を所有していて、小さなインスタンスを実行している場合の RI には小さなインスタンスの料金が適用されます。ただし、未使用の予約が蓄積されることはありません。

提供開始
今すぐこの新たな柔軟性をご利用いただけます。これはリージョンの共有テナンシーを使用している Linux/UNIX RI で自動的に適用されます。お客様からの操作は必要ありません。

Jeff;

AWS Microsoft ADとオンプレミスの資格情報を使用してAWS管理コンソールにアクセスする方法

これは、AWS Security blogに投稿された「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」の翻訳記事です。


 

AWS Microsoft ADと略される、AWS Directory Service for Microsoft Active Directory は、AW​​Sクラウドにホストされた管理されたMicrosoft Active Directory(AD)です。オンプレミスのAD管理ツールを使用して、AWSリソースを管理する権限をユーザに簡単に付与できます。AWS Microsoft ADを使用すると、Identity and Access Management(IAM)を利用してAWSリソースへのアクセス管理をしたり、セキュリティアサーションマークアップ言語(SAML)でADフェデレーションサービス(AD FS)を構成する代わりに、オンプレミスユーザーにAWS管理コンソールなどのリソースへのアクセス許可を与えることができます。

このブログ記事では、AWS Microsoft ADを使用してオンプレミスのADユーザーがオンプレミスのADユーザー資格情報を使用してAWS管理コンソールにサインインし、IAMロールを通じてAWSリソースにアクセスして管理する方法を示します。

 

概要

AWSのお客様は、オンプレミスADを使用してユーザーアカウントを管理し、グループメンバーシップを管理し、オンプレミスリソースへのアクセスを制御します。 多くのAWS Microsoft ADのお客様がいる場合は、オンプレミスのAD資格情報を使用してAWS管理コンソールにサインインして、 Amazon EC2Amazon RDSAmazon S3などのAWSリソースを管理できるようにすることもできます。

このようなサインインパーミッションを有効にすると、主に4つの利点があります。

  1. オンプレミスのADグループ管理者は、IAMの代わりに標準のAD管理ツールを使用して、AWSリソースへのアクセスを管理できるようになります。
  2. ユーザーは、ADとAWS Management Consoleにサインインするために1つのIDのみを記憶すればよくなります。
  3. ユーザーはオンプレミスのAD資格情報でサインインするため、AWS管理コンソールへのアクセスには、AD強制パスワードポリシーの量可能になります。
  4. ADからユーザーを削除すると、AWS Microsoft ADとIAMは自動的にAWSリソースへのアクセスを取り消します。

IAMロールは、AWSリソースを管理する権限を定義する便利な方法を提供します。 AWS Microsoft ADとオンプレミスADの間のAD信頼関係を使用することで、オンプレミスのADユーザーとグループをIAMロールに割り当てることができます。 これにより、割り当てられたユーザとグループにAWSリソースを管理するためのIAMロールの権限が与えられます。 オンプレミスのADグループをIAMロールに割り当てることで、ADユーザとコンピュータ(ADUC)などの標準的なAD管理ツールを使用してAWSアクセスを管理できるようになります。

オンプレミスのユーザーやグループをIAMロールに割り当てた後、ユーザーはオンプレミスのAD資格情報を使用してAWS管理コンソールにサインインできます。 そこから、割り当てられたIAMロールのリストを選択できます。 ロールを選択すると、IAMロールに割り当てた管理機能を実行できます。

この記事の残りの部分では、これを4つのステップで達成する方法を示します。

  1. アクセスURLの作成。
  2. AWS管理コンソールへのアクセスの有効化。
  3. オンプレミスのユーザーとグループをIAMロールへの割り当て。
  4. AWS管理コンソールへの接続。

 

前提条件

このブログ記事の指示に従い、次のコンポーネントを実行する必要があります。

  • AWSクラウドで作成されたMicrosoft ADディレクトリ。 詳細については、「Create a Microsoft AD Directory」を参照してください。
  • 既存のオンプレミスActive Directory。
  • AWS Microsoft ADからオンプレミスActive Directoryへの双方向におけるフォレストの信頼関係。 詳細は、「Now Available: Simplified Configuration of Trust Relationships in the AWS Directory Service Console」を参照してください。 信頼に関する追加情報、およびAWS管理コンソールへのドメインレスサインインのアクセス方法については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。
  • AWSディレクトリサービスに設定された信頼関係を持つIAMロール。 これを行うにはヘルプが必要な場合は、「Editing the Trust Relationship for an Existing Role」を参照してください。

注: AWS Microsoft ADに格納されているユーザーIDにIAMロールを割り当てることができます。この記事では、オンプレミスのADに格納されているユーザーIDにIAMロールを割り当てることに重点を置いています。 これには、オンプレミスのActive DirectoryとAWS Microsoft ADディレクトリの間にフォレストの信頼関係が必要です。

 

ソリューションの概要

私が自分の会社のADとIAMロールの両方を管理する管理者だとします。私の会社では、全従業員がオンプレミスの資格情報を使用してAWS管理コンソールにサインインし、AWSリソースにアクセスして管理できるようにしたいと考えています。私の会社はEC2、RDS、S3を使用しています。これらのリソースへの管理権限を管理するために、サービスに完全にアクセスできるように各サービスの権限を作成しました。これらのロールにEC2FullAccess、RDSFullAccess、および、S3FullAccessという名前を付けました 。

私の会社には責任の異なる2つのチームがあり、ADセキュリティグループのユーザーを管理しています。 MaryはDevOpsセキュリティグループのメンバーであり、RDSデータベースの作成と管理、EC2でのデータ収集アプリケーションの実行、S3での情報のアーカイブを担当しています。JohnとRichardはBIMgrsセキュリティグループのメンバーで、EC2を使用してデータベースに対して分析プログラムを実行します。 JohnンとRichardはデータベースとアーカイブされた情報にアクセスする必要がありますが、それらのシステムを操作する必要はありません。EC2インスタンスを管理するための許可が必要です。

AWSリソースへの適切なアクセスを許可するには、ADのBIMgrsセキュリティグループをIAMのEC2FullAccessロールに割り当て、 DevOpsグループを3つのロール(EC2FullAccess 、RDSFullAccess、およびS3FullAccess)すべてに割り当てる必要があります。また、AWS Management Consoleにサインインした後で、従業員全員が十分な管理作業を完了できるようにしたいので、コンソールセッションタイムアウトを60分から240分(4時間)に増やします。

次の図は、私の会社のADユーザーとグループと私の会社のAWSの権限とサービスの関係を示しています。 図の左側は、ユーザーとグループを含む私のオンプレミスのADを表しています。 右側は、AWS管理コンソール、AWSリソース、IAMロール、およびオンプレミスADにフォレストの信頼関係を介して接続されたAWS Microsoft ADディレクトリを含むAWSクラウドを表しています。

 

このシナリオの手順を開始しましょう。この記事では、すでにAWS Microsoft ADディレクトリが作成されており、AWS Microsoft ADからオンプレミスADへの双方向フォレストの信頼を確立しています。AWSリソースへのアクセスを管理するため、以下のIAMロールも作成してあります。

  • EC2FullAccess :EC2へのフルアクセスを提供し、 AmazonEC2FullAccess AWS管理ポリシーを添付します。
  • RDSFullAccess :AWS管理コンソール経由でRDSへのフルアクセスを提供し、 AmazonRDSFullAccess管理ポリシーを添付します。
  • S3FullAccess :AWS管理コンソール経由でS3へのフルアクセスを提供し、 AmazonS3FullAccess管理ポリシーを添付します。

IAMロールを作成して管理ポリシーを添付する方法の詳細については、「管理ポリシーのアタッチ」を参照してください。

注: Microsoft ADを使用してAWS管理コンソールにサインインするユーザーがアクセスする必要があるすべてのロールに、ディレクトリサービス信頼ポリシーを含める必要があります。 詳細は、「Editing the Trust Relationship for an Existing Role」を参照してください。

 

ステップ1 – アクセスURLを作成する

AWS Management Consoleへのアクセスを有効にするための最初の手順は、AWS Microsoft ADディレクトリのための一意のアクセスURLを作成することです。アクセスURLは、グローバルに一意のURLです。AWS管理コンソールなどのAWSアプリケーションは、URLを使用して、AWS Microsoft ADディレクトリにリンクされているAWSサインインページに接続します。 アクセスURLは、ディレクトリへの他のアクセスを提供しません。 アクセスURLの詳細については、「Creating an Access URL」を参照してください。

アクセスURLを作成するには、次の手順を実行します。

 

  1. ディレクトリサービスコンソールに移動し、AWS Microsoft AD Directory IDを選択します。
  2. Directory Detailsページで、Apps & Services タブを選択し 、Access URL ボックスに一意のアクセスエイリアスを入力し、 Create Access URLを選択してディレクトリのアクセスURLを作成します。ディレクトリのアクセスURLは、 <access-alias> .awsapps.comという形式にする必要があります。 この例では、 https://example-corp.awsapps.comを使用しています。

 

ステップ2 – AWS管理コンソールへのアクセスを有効にする

ユーザがオンプレミスの認証情報でAWS Management Consoleにサインインできるようにするには、AWS Microsoft ADディレクトリのAWS管理コンソールアクセスを有効にする必要があります。

  1. ディレクトリサービスコンソールから、AWS Microsoft AD Directory IDを選択します。 AWS apps & servicesセクションのAWS Management Consoleリンクを選択します。
  2. Enable AWS Management Consoleダイアログボックスで、 Enable Accessを選択して、ディレクトリに対するコンソールアクセスを有効にします。

    これにより、AWS Microsoft ADディレクトリのAWS Management Consoleへのアクセスが可能になり、コンソールに接続するためのURLが提供されます。 URLは、ステップ1: <access-alias>.awsapps.com/consoleで作成したアクセスURLの末尾に「 /console 」を付加して生成されます。 この例では、AWS管理コンソールのURLは、https://example-corp.awsapps.com/consoleです。

 

ステップ3 – オンプレミスのユーザーおよびグループをIAMロールに割り当てる

ユーザーがアクセスURLを使用してAWS管理コンソールにサインインする前に、オンプレミスのユーザーまたはグループをIAMロールに割り当てる必要があります。このステップで、オンプレミスのユーザーおよびグループがAWS管理コンソールからアクセス可能なAWSリソースを制御できます。

私のオンプレミスのActive Directoryでは、 Maryは既にDevOpsグループのメンバーであり、JohnとRichardはBIMgrsグループのメンバーです。私はすでにAWS Microsoft ADから私のオンプレミスADへの信頼関係を確立しました。EC2FullAccess 、RDSFullAccessおよびS3FullAccessの権限を作成できました。

これで、オンプレミスグループをIAMロールに割り当てる準備が整いました。私はDevOpsグループをEC2FullAccess、RDSFullAccess 、およびS3FullAccess IAMロールに割り当て、BIMgrsグループをEC2FullAccess IAMロールに割り当てます。オンプレミスグループをIAMロールに割り当てるには、次の手順に従います。

  1. AWS Microsoft ADディレクトリのディレクトリサービスの詳細ページを開き、Apps & servicesタブのAWS Management Console リンクを選択します。 Continue を選択して、 Add Users and Groups to Rolesページに移動します。
  2. Add Users and Groups to Rolesページでは、既に設定した3つのIAMロールが表示されます(次のスクリーンショットを参照)。 ディレクトリサービス信頼ポリシーが有効なIAMロールがない場合は、 新しいロールを作成するか、既存のロールに対してディレクトリサービスを有効にすることができます。
  3. オンプレミスのDevOpsグループとBIMgrsグループをEC2FullAccessロールに割り当てます。これを行うために、私はEC2FullAccess IAMロールリンクを選択して、Role Detailページに移動します。 次に、次のスクリーンショットに示すように、 Addボタンをクリックしてユーザーまたはグループをロールに割り当てます。
  4. Add Users and Groups to Role ポップアップウィンドウで、割り当てるユーザーとグループを含むオンプレミスのActive Directoryフォレストを選択します。 この例では、そのフォレストはamazondomains.comです。 注:オンプレミスADへの信頼を使用せず、AWS Microsoft ADディレクトリにユーザーとグループを作成する場合は、 このフォレストのデフォルトを選択してMicrosoft ADのユーザーを検索できます。
  5. Active Directoryグループを割り当てるには、Search forフィールドの上にあるGroupフィルタを選択します。 検索ボックスにActive Directoryグループの名前を入力し、検索ボタン(虫眼鏡のマークを選択します。 私はオンプレミスのActive DirectoryからDevOpsグループを検索できたことがわかります。
  6. この例では、社内のグループDevOpsとBIMgrsをEC2FullAccessロールに追加しています。終了したら、Addボタンを選択して、ユーザとグループをIAMロールに割り当てます。 これで、DevOpsとBIMgrsオンプレミスADグループにEC2へのフルアクセスが正常に付与されました。これらのADグループのユーザは、自社の認証情報を使用してAWS管理コンソールにサインインし、EC2インスタンスを管理できるようになりました。
    Add Users and Groups to Rolesページから、残りのグループをIAMロールに割り当てるプロセスを繰り返します。次のスクリーンショットでは、DevOpsグループを3つのロールに、BIMgrsグループを1つのロールに割り当てたことがわかります。
    ADセキュリティグループを自分のIAMロールに割り当てることで、オンプレミスユーザーをセキュリティグループに追加および削除して、IAMロールへのアクセス許可を付与または取り消すことができます。これらのセキュリティグループのユーザーは、割り当てられたすべての権限にアクセスできます。
  7. オプションで、AWS Microsoft ADディレクトリのログインセッション長を設定できます。デフォルトの長さは1時間ですが、最大12時間まで延長できます。私の例では、コンソールのセッション時間を240分(4時間)に設定しています。

 

ステップ4 – AWS管理コンソールに接続する

私は、ユーザが自社の認証情報でAWS Management Consoleにサインインできるようになりました。 ステップ2で作成したアクセスURL: https://example-corp.awsapps.com/consoleを自社のユーザーにメールで送信しました。 これで、ユーザーはURLにアクセスしてAWS Management Consoleにサインインできます。

DevOpsグループのメンバーであるMaryがアクセスURLにアクセスすると、AWS Management Consoleに接続するためのサインインページが表示されます。 Usernameボックスでは、3つの方法でサインイン名を入力できます。

  • 社内のNetBIOSログイン名(corp\mary)の指定。
  • 彼女の完全修飾ドメイン名(FQDN)のログイン名( amazondomains.com\mary)の指定。
  • ドメインなしのログインで彼女のユーザー名だけを使用。ドメインレスログインの詳細については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。

DevOpsグループは3つのIAMロールに関連付けられており、MaryはDevOpsグループに属しているため、ログイン後に表示されるリストから希望するロールを選択できます。次のスクリーンショットはこのステップを示しています。

マルチファクタ認証(MFA)を使用してAWS管理コンソールを保護する場合は、AWS Microsoft AD設定にMFAを追加することもできます。 Microsoft ADでMFAを有効にする方法の詳細については、「How to Enable Multi-Factor Authentication for AWS Services by Using AWS Microsoft AD and On-Premises Credentials」を参照してください。

まとめ

AWS Microsoft ADを使用すると、オンプレミスの資格情報を使用してAWS管理コンソールに簡単に接続できます。 また、AWSリソースへのアクセスを制御しながら、パスワード有効期限、パスワード履歴、アカウントロックアウトポリシーなどの社内ADセキュリティポリシーを再利用することもできます。

ディレクトリサービスの詳細については、 AWS Directory Serviceのホームページを参照してください 。 このブログの投稿に関するご質問がある場合は、 ディレクトリサービスフォーラムで新しいスレッドを開始してください。

– Vijay


 

翻訳:瀧澤与一(原文:「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」 – https://aws.amazon.com/blogs/security/how-to-access-the-aws-management-console-using-aws-microsoft-ad-and-your-on-premises-credentials/

Amazon RDS for MySQL バージョン: 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23 リタイアメントのお知らせ

Amazon RDS for MySQLにおいて、MySQLのマイナーバージョン 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23 のサポートを2017年7月19日に終了致します。これらのバージョンはAmazon RDSで2014年10月から2015年6月にかけてサポートされました。そして、新機能やセキュリティ・安定性向上を含んだバージョンに更新されてきました。

現在これらのバージョンをご利用の場合、現在サポートされているMySQLの最新のマイナーバージョン(2017/3/8現在: 5.6.34)にアップグレードを行うことを推奨致します。メジャーバージョンアップグレードと異なり、マイナーバージョンアップグレードはそれ以前データベースエンジンのマイナーバージョンと後方互換性を持っています。

2017年4月5日Auto Minor Version UpgradeがYesに設定されているDBインスタンスに対して、自動アップグレードを設定致します。アップグレードはこの日以降の通常のメンテナンスウインドウ内で順次実施されます。

2017年7月5日以降に起動しているMySQL 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23バージョンのRDS DBインスタンスは、Auto Minor Version Upgradeの設定に関わらず自動的に最新のマイナーバージョンに、各インスタンスに設定されているにメンテナンスウインドウ内でアップグレードが行われます。

2017年7月19日以降に起動している該当バージョンのRDS MySQLインスタンスは、メンテナンスウインドウに関わらず即座にアップグレードが実施されます。

RDSでのMySQLのマイナーバージョンアップグレードについては、こちらをご覧ください。

不明点などがありましたら、AWS サポートチームへコミュニティフォーラムかサポートセンター経由でご連絡下さい。

今回のアップグレードは、2017年4月5日到来前にアップグレード対象バージョン以上のマイナーバージョンもしくは、メジャーバージョンにアップグレードして頂くことで回避可能です。そのため、テスト環境などでテストを行っていただき、自動適用が開始される前に手動でアップグレードすることをお勧め致します。

 

原文はこちらをご覧ください。

 

Amazon Aurora: 暗号化されたスナップショット・データベースに対する新機能

本日Amazon Auroraの新機能を2つリリース致しました。

暗号化済みデータベースのクロスリージョンサポート

暗号化済みのデータベースでAWSリージョンをまたいだレプリケーションがサポートされました。クロスリージョンレプリケーションを利用することで、ユーザに近い場所でリードオペレーションを実行することが可能になったり、ディザスターリカバリー環境を簡単に構築出来ます。また、リージョンをまたいだデータベースの移行も容易に行なえます。

また、暗号化されたスナップショットをAWSリージョン間でコピー可能になりました。開発チームとテストチームが様々な地域に分散していたとしても、本番データベースの最新のコピーを安全に共有することによって、グローバルな開発プロセスを構築できます。また、遠隔地にスナップショットを安全に保管することで、ディザスターリカバリー戦略を強化することも可能です。

詳細は、クロスリージョンレプリケーションクロスリージョンスナップショットコピーのドキュメントをご覧ください。

 

AWSアカウント間で暗号化済みスナップショット共有をサポート

AWSアカウント間で暗号化済みスナップショットの共有が可能になりました。暗号化キーを共有しているアカウントを分離するためにAuroraのセキュリティモデルを拡張出来ます。他のアカウントの所有者は、スナップショットをコピーしたり、スナップショットからデータベースインスタンスを復元することができます。

詳細なドキュメントはこちらをご覧ください。

Amazon Auroraは、フルマネージド、高可用性、コストパフォーマンスのよいリレーショナルデータベースです。MySQLと互換性があるためアプリケーションコードの変更なしに移行が行なえます。また、こちらのツールを利用することでダウンタイムを最小限に移行を行うことも可能です。

翻訳は星野が担当しました。原文は、Amazon Aurora Announces Encryption Support for Globally Distributed Database DeploymentsAmazon Aurora Supports Cross-Account Encrypted Snapshot Sharing

 

 

 

 

 

 

Amazon Elasticsearch Service をはじめよう: シャード数の算出方法

Dr. Jon Handler (@_searchgeek) は検索技術にスペシャライズした Amazon Web Services のプリンシパルソリューションアーキテクトです。

Elasticsearch および Amazon Elasticsearch Service(Amazon ES) のブログポストシリーズへようこそ。ここでは今後もAWS上でElasticsearchをはじめるにあたって必要な情報を提供していく予定です。

いくつのシャードが必要?

Elasticsearchは、大量のデータを、シャードと呼ばれる細かいユニットに分割し、それらのシャードを複数のインスタンスに分散して保持します。Elasticsearchではインデックス作成の際にシャード数を設定します。既存のインデックスのシャード数を変更することは出来ないため、最初のドキュメントをインデックスに投入する前にシャード数を決定しなければなりません。最初はインデックスのサイズからシャード数を算出するにあたって、それぞれのシャードのサイズの目安を30GBにします。

シャード数 = インデックスのサイズ / 30GB

インデックスのサイズ算出に関しては、AWS Solutions Architect ブログ: 【AWS Database Blog】Amazon Elasticsearch Service をはじめよう: インスタンス数の見積もり方法をご覧ください。

データの送信やクエリをクラスタに対して行っていく中で、クラスタのパフォーマンスを元に、継続的にリソースのユーセージを評価しながら、シャード数を調整していきます。

シャードとは?

What is Shard

サーチエンジンには2つの役割があります: ドキュメントを元にしたインデックスの作成と、インデックスの中からマッチしたドキュメントを引き当てる検索です。インデックスが小さければ一つのデータ構造で一台のマシンで事足りるでしょう。しかし、大量のドキュメントにおいては、インデックスを保存するのに一台のマシンでは足りませんし、ピースに分割されたインデックスから検索結果を求めるためのコンピュート能力も足りません。Elasticsearchではこれらのピースのことをシャードと呼びます。それぞれのドキュメントは計算結果に基いてシャードにルーティングされます。デフォルトではドキュメントのIDのハッシュ値に基づいたルーティングになります。

シャードは ストレージ(storage) の単位であり、また 処理(computation) の単位でもあります。Elasticsearchはシャードを独立した形でクラスタ内のインスタンスにデプロイし、インデックスの処理をそれぞれで並列に行います。Elasticsearchという名前の通り”elastic”なものであると言えるでしょう。クラスタにインスタンスを追加する場合、Amazon Elasticsearch Serviceは自動的にシャードのリバランスを行い、クラスタ内のインスタンスにシャードを再配置します。

ストレージ(storage)においては、シャードはそれぞれ別のもの(distinct)です。シャード内のドキュメントは、他のシャードに重複して保持されることはありません。このアプローチによってシャード毎の独立性を保っています。

処理(computation)においても、シャードはそれぞれ別のもの(distinct)です。それぞれのシャードはドキュメントが処理されて生成されたApache Lucene indexのインスタンスです。インデックスには全てのシャードが含まれるため、クエリや更新リクエストのプロセスにおいて、それぞれのシャードはお互いに協調して機能する必要があります。クエリのプロセスにおいては、Elasticsearchはインデックス内の全てのシャードにクエリをルーティングします。それぞれのシャードはローカルで個別に処理を行い、それぞれの結果をアグリゲートして最終的にレスポンスします。書き込みリクエストにおいては(ドキュメントの追加、もしくは、既存のドキュメントの更新)、Elasticsearchはリクエストを適切なシャードにルーティングします。

Elasticsearchには2つの種類のシャードがある

Elasticsearchには2つの種類のシャードがあります – プライマリシャードとレプリカシャードです。プライマリシャードは全ての書き込みリクエストを受け付けます。プライマリシャードは新しく追加されたドキュメントをレプリカにパスします。デフォルトでは、書き込みがレプリカに確認(acknowledge)されるのを待ってから呼び出し元に書き込み成功のレスポンスを行います。プライマリとレプリカシャードはデータの保存に冗長性をもたらし、データのロスを起こりにくくします。

ES Cluster 1

この図の例では、Elasticsearchクラスタは3つのデータインスタンスを保持しています。緑と青の2つのインデックスがあり、それぞれ3つのシャードがあります。それぞれのシャードのプライマリは赤枠で囲われています。それぞれのシャードにはレプリカがあり、それらに枠はありません。Elasticsearchはいくつかのルールを元にシャードをインスタンスに配置します。最も基本的なルールとして、プライマリとレプリカのシャードを同じインスタンスに配置しない、というものが挙げられます。

最初にストレージにフォーカスする

お客様のワークロードには2つの種類があります: シングルインデックスとローリングインデックス。シングルインデックスのワークロードは、全てのコンテンツを保持する”source of truth”な外部のリポジトリを使い、データは一つのインデックスに保持されます。ローリングインデックスのワークロードは、データを継続的に受け取り、データはタイムスタンプによって(通常は1日24時間)異なるインデックスに保持されます。

それぞれのワークロードにおけるシャーディングの計算のスタート地点は、インデックスに必要なストレージサイズです。それぞれのシャードをストレージの単位として扱うと、いくつのシャードが必要になるかのベースラインを見出すことが出来ます。シングルインデックスのワークロードであれば、トータルのストレージ容量を30GBで割って最初に必要なシャード数を算出します。ローリングインデックスのワークロードの場合は一期間のインデックスのサイズを30GBで割ることで最初のシャード数を算出します。

シングルシャードを恐れるな!

もし、あなたのインデックスのサイズが30GB以下であるのであれば、一つのシャードのみを使うべきです。”more is better”というガッツフィーリングをお持ちの方もいらっしゃいますが、誘惑を断ち切りましょう! シャードは処理とストレージのエンティティであり、あなたが追加するシャードによってインデックスに対するリクエストはアディショナルなCPUに分散されて処理されます。必要以上のプロセッサーを使うことで、その管理や処理結果の結合などに追加で処理が必要になり、パフォーマンスが下がることにつながります。scatter-gatherなクエリおよびレスポンスにおけるネットワークのオーバーヘッドもかかるでしょう。

シャード数の設定

Elasticsearchのインデックス作成APIを叩いく際にシャード数を設定します。Amazon Elasticsearch ServiceでのAPIコールは以下のようになります:

>>> curl –XPUT https://search-tweets-EXAMPLE.us-west-2.es.amazonaws.com/tweet -d '{
  "settings": {
    "index" : {
      "number_of_shards": 2,
      "number_of_replicas": 1
    }
  }
}'

シングルインデックスのワークロードの場合、この設定を行うのはインデックスを最初に作成する際の1回のみですが、ローリングインデックスのワークロードの場合、インデックスを定期的に作成することになります。その場合は _template APIを使って、テンプレートにマッチする新しいインデックスには自動的に設定が適用されるようにします。

>>> curl –XPUT https://search-tweets-EXAMPLE.us-west-2.es.amazonaws.com/_template/template1 -d '{
  "template": "logs*",
  "settings": {
    "index" : {
      "number_of_shards": 2,
      "number_of_replicas": 1
    }
  }
}'

この例では、”log”というプレフィックスで作られたインデックスは、2つのシャードと1つのレプリカを保持します。

ワークロードに合わせた調整

今回カバーした内容は最もシンプルなシャーディングに関することでしたが、今後のポストではユーセージを元にしたシャード数の調整といったネクストレベルなところまで踏み込む予定です。もし、はじめたばかりであれば、30GBでインデックスのサイズを割り算することでシャード数を算出しましょう。データをインデックスに投入する前にシャード数を設定するのをお忘れなく。

あなたのシャーディングアドベンチャーのエピソードを是非お聞かせください!

Amazon Elasticsearch Serviceのより詳細な情報に関しては、https://aws.amazon.com/jp/elasticsearch-service/ をご覧ください。

 

原文:Get Started with Amazon Elasticsearch Service: How Many Shards Do I Need?(翻訳:篠原 英治)