Amazon Web Services ブログ

事前にご確認ください - AWSでのうるう秒対応【更新】

同僚の Mingxue Zhao がゲストポストを投稿してくれました。これは今後発生する重要な時刻調整についての説明です。

注：このブログは最初2015年5月18日にポストされましたが、その後5月25日に追記・修正版としてポストされたものです（訳注：翻訳版も25日の内容に合わせて更新しています）

— Jeff;

---

IERS(The International Earth Rotation and Reference Systems)は、標準時刻に対し2015年6月30日に追加の1秒を挿入するとアナウンスしました。これは、6月30日の最後の1分には61秒目が存在するということです。もし時刻を標準時と同期している場合、この追加の秒が23:59:60として、23:59:59と00:00:00の間に表示されることになります。この追加の1秒をうるう秒と呼びます。このような「うるう秒の挿入」は1972年から25回実施され、最近では2012年6月30日に実施されています。（※補足：これはUTC時間ですので、日本時間では7月1日午前9時になります）

全てのITシステムのクロックがこの標準時にそのまま追従するわけではなく、色々な方法で対応を行います。例えば以下のような例があります：

• いくつかのLinuxカーネルのインプリメンテーションは、":60"の秒を追加する代わりに、１秒戻る動作を行います。つまり59秒目を繰りかえすようになっています。（詳細はこちらの資料をご覧ください（英文） Resolve Leap Second Issues in Red Hat Enterprise Linux ）
• Windows 時刻サーバ(Windows time server)はうるう秒のシグナルを無視し、うるう秒挿入後に正しい時刻に同期します。（詳細はこちらの資料をご覧ください（英文） How the Windows Time Service Treats a Leap Second ）
• AWSを含むいくつかの組織では、１秒をごくわずかに遅くすることで、追加される１秒を長い時間のなかに分散する方法で対応することを計画しています
• もしクロックが時刻同期システムに接続していない場合、そのまま動作し、うるう秒が挿入されることはありません。もしくは別途調整されます

もしご自身のアプリケーションやシステムが適切にうるう秒をハンドリングできるかどうかを知りたい場合は、それを提供している提供元にまずコンタクトをしてください。そしてもし、時刻に非常に厳密に動くワークロードがあり、そのためにAWSのクロックの挙動について知りたい場合は、このドキュメントを注意深くお読みください。大きく分けて３つのパートに影響がありえます：

• AWSマネジメントコンソールと、バックエンドシステム
• Amazon EC2 インスタンス
• その他のAWSリソース

AWSクロックと、UTCとの比較についての詳細は、以下のAWS調整時刻(AWS Adjusted Time)のセクションで説明しています。

AWSマネジメントコンソールと、バックエンドシステム

AWSマネジメントコンソールとバックエンドシステムは、うるう秒をハンドリングするようには実装されていません。代わりに、２４時間という期間に渡って、各１秒１秒をごくわずかだけ遅くすることで、うるう秒の挿入された標準時(UTC)とのズレが無くなるように調整されます。このためAWSクロックは最大で、標準時から0.5秒遅れ、もしくは0.5秒先行します。（詳しくは以下のAWS調整時刻(AWS Adjusted Time)を読んでください）

この調整の結果、コンソールにおける値（リソースを作成したタイムスタンプ等）の他、CloudFront や CloudTrail のログに":60" といった記録は残りません。同様にビリング（支払い）画面においても、この調整済み時刻で利用料金が計上されます。

Amazon EC2 インスタンス

EC2インスタンスにおける挙動は、それぞれの設定によりますが、AWS 側でインスタンス内部の時刻同期を管理することはありません。上述したような挙動になると考えられますので、ご利用OSの供給元に問い合わせていただき、想定される挙動について確認をしてください。

Amazon Linux AMIをお使いの場合は、EC2インスタンスは１秒戻す挙動が実施されます。つまり23:59:59を2回表示することになります。以下に詳細な情報があります。

• フォーラムへのポスト: Amazon Linux AMI and the 2015-06-30 leap second.

EC2インスタンスの時刻を調整する必要がある場合には、以下の資料を参照してください。

• Amazon Linux AMIの場合:　Linux インスタンスの時刻の設定
• Amazonが提供するWindows AMIの場合: Windowsインスタンスの時刻を設定する
• その他のAMIを利用したインスタンス: AMIの提供元にお問い合わせください

その他のAWSリソース

他のAWSリソースは、それぞれのクロックを持っています。EC2とは異なり、AWS側で対応されるため、ユーザ側で対応する必要はありません。（注：お客様管理下でEC2のインスタンスを起動するサービスを除きます）。

以下のリソースでは１秒戻すように実装されており、23:59:59が２回表示されます。

• Amazon CloudSearch クラスター
• Amazon EC2 Container Service インスタンス
• Amazon EMR クラスター
• Amazon RDS インスタンス
• Amazon Redshift インスタンス

EMRクラスターで時刻同期を実施するには、VPC環境からNTPへアクセスできる必要があります。ご利用のEMRクラスターがインターネットへアクセスでき、セキュリティグループやネットワークACLがUDPポート123への通信を許可しているかを確認してください。

AWS調整時刻(AWS Adjusted Time)

このセクションでは、AWSマネジメントコンソールやバックエンドシステムで、どのようにクロックが動作するかの詳細を説明します。

2015年6月30日 12:00:00PM(お昼の12時)から、AWSクロックが毎秒あたり1/86400秒だけ遅くなります。つまりAWSクロックでの１秒の経過が、実際の時刻では1+1/86400秒の経過になります。この処理が2015年7月１日の12:00:00PM（お昼の１２時）までの24時間にわたって続くことによって、ちょうど１秒分実際の時刻より遅れた状態になります。この調整期間の最中である2015年6月30日の終わりに標準時（UTC）にはうるう秒が挿入され、こちらも１秒だけ時刻が遅くなります。結果として2015年7月1日の12:00:00PM(お昼の12時)には、AWSクロックとUTCは完全に同じ時刻を指すようになります。以下の表でこの変化を説明しましょう。

UTC	AWS調整時刻	AWS vs. UTC	注記
11:59:59 AM 2015/06/30	11:59:59 AM 2015/06/30	+0	AWSクロックはUTCと同期しています。
12:00:00 PM	12:00:00 PM	+0
12:00:01			AWSクロックの各1秒が1/86400だけ長くなり、UTCから遅れ始めます。少しづつ差が開いていき、最大で1/2秒の差になります。
	12:00:01	+1/86400
12:00:02
	12:00:02	+2/86400
…	…	…
23:59:59
	23:59:59	+43199/86400
23:59:60			UTCにうるう秒が挿入されます。
	00:00:00 AM 2015/07/01	-1/2	UTCが1秒遅れた結果として、AWSクロックはUTCより1/2秒進んでいる状態になります。
00:00:00 AM 2015/07/01			AWSクロックは依然速度を落としたままのため、少しづつUTCとのギャップが縮まっていきます。
	00:00:01	-43199/86400
00:00:01
	00:00:02	-43198/86400
…	…	…
	11:59:59 AM	-1/86400
11:59:59 AM
12:00:00 PM 2015/07/01	12:00:00 PM 2015/07/01	+0	ギャップがゼロになりました。この時点でAWSとUTCは同期され、この後は同じ時刻を指すようになります。
12:00:01	12:00:01	+0
…	…	…

 

この現象についてご質問がある場合はAWSサポートにご連絡いただくか、EC2フォーラムで質問をしてください。

— Mingxue Zhao, シニアプロダクトマネージャー（翻訳：下佐粉 昭）

【AWS発表】CloudSearch アップデート - 値下げ、ヘブライ語・日本語サポート改善、パーティショニング、CloudTrail対応

Amazon CloudSearch を既にお使いのお客様やご検討中のお客様にいいニュースをお伝えします。既にご存知かもしれませんが、CloudSearch は Web サイトやアプリケーションのための簡単にセットアップ、運用、スケールさせることができるフルマネージド型の検索サービスです。CloudSearch をお使いであれば、値下げや追加の言語サポート、ドメインパーティショニングの制御（この機能は今年の前半にリリースしましたがこれまでブログでお知らせする機会がありませんでした）が役に立つと思います。また最近リリースされた AWS CloudTrail のサポートも活用頂けると思います。

値下げ

ますます多くの AWS のお客様に CloudSearch が採用され始めており、それに応じて規模が拡大しています。全リージョンにおいて CloudSearch 検索インスタンスタイプの時間課金を最大 50% 値下げします。この変更は2014年11月1日から適用され、お客様にて何も実施頂く必要はありません。これにより、CloudSearch を利用するのと、検索インフラをセットアップして、動作させ、スケールさせることのコストを比較すると、トータルコストがより有利になりました。

詳しくは CloudSearch の料金ページを御覧ください。

追加の言語サポート

今年の初めヘブライ語に特化したテキスト処理を紹介しました。この追加で、現在 CloudSearch は合計 34 言語をサポートしています。以下はヘブライ語のコンテンツを検索した結果です。：

10月中旬、日本語用にカスタムのトークナイズ辞書を追加サポートしました。これにより CloudSearch がどのように日本語をトークナイズするかを制御することができます。日本語テキストが含まれているフィールドに使用する分析スキーマにカスタムのトークナイズ辞書を追加して制御します。詳しくは、CloudSearch の開発者ガイドにあるCustomizing Japanese Tokenization を御覧ください（本ブログ記載時点ではまだ日本語化されていませんので英語版を御覧ください）。

パーティショニングを制御

m2.2xlarge の検索インスタンスタイプを使用されている場合は、お使いの検索ドメインでのインデックスパーティション数を事前に設定できるようになっています。ドメインを事前に設定することで、大規模なアップロードのパフォーマンスが改善されます。パーティションを追加することで、パーティションあたりのドキュメント数を軽減しクエリパフォーマンスを向上させることもできます。CloudSearch は引き続きデータやトラフィック量に応じてドメインをスケールアップ・ダウンしますが、希望パーティション数を下回ることはありません。AWS マネジメントコンソール、CloudSearch API、AWS コマンドラインインターフェース (CLI) からパーティション数を制御することができます。検索ドメインを作成する際は以下のように設定することができます。:

後から変更することもできます。:

CloudTrail サポート

先月、CloudSearch は AWS CloudTrail サポートを追加しました。現在、CloudSearch API が呼び出された履歴を CloudTrail で得られるようになっています。呼び出しは記録されて、Amazon S3 バケットに保存されます。より詳細については、Logging Amazon CloudSearch Configuration Service Calls Using AWS CloudTrail を御覧ください。

辻

【AWS発表】Amazon CloudSearch 大幅アップデート - 1ヶ月100ドル以下でより良い検索が可能に！日本語にも対応！

過去に私が言ったように、多くのウェブサイトやオンラインアプリケーションにおいて、検索は重要な役割を果たしています！

基本的なモデルはシンプルです。複数のページからなる本やカタログのような、ドキュメントセットやデータの塊を考えてみてください。 単純にインデックスを参照することにより、迅速かつ効率的に目的のページを見つけることができることはご存知の通りです。

検索は目的のデータを高速に見つけるために各ドキュメントをインデックス化することにより、それと同じことをしています。 検索ボックスに文字列を入力すると、サイトはその検索文字列にマッチするページの一覧を返します。普通はリストの上位に最も良くマッチしたページが表示されるようソートされます。

CloudSearch
2012年の4月に発表されたAmazon CloudSearchは、フルマネージドなサービスで、基本的な検索機能の構築、そのスケーリングや、可用性を高める対策などを気にすることなく、アプリケーションに検索機能を追加することにフォーカスすることができます。

本日、このCloudSearchに多くの主要な機能強化を行ったことを発表いたします。新しいインデックス作成および検索機能、合計33言語のサポート、IAM統合、インスタンスサイズとスケーリングの制御、可用性を高めるためのMulti-AZオプションなど、多くの機能を追加いたしました。 また、CloudSearchのコンソールも大幅な改良を加えています。

これらの機能については、この記事で追ってご紹介いたしますが、その前に、CloudSearchのような、マネージドサービスのコンセプトについて、見直してみたいと思います。

マネージドサービス
AWSの辞書では、マネージドサービスはサービスの実行に関連する厄介な物事の面倒をすべて見ることを指します。 エラーが発生しやすい人間の介入と詳細なrunbooksに必要な活動は、 慎重に設計され、徹底的にテストされたワークフローに置き換えられ、包括的なモニタリングによって検証されます。

マネージドサービスは、プロビジョニング、スケーリング、障害検出および回復、オペレーティングシステムおよびサービスのアップデート、動作条件の変更を自動的に処理することができます。

マネージドサービスは世界規模で実行されるため、ワークフローはあらゆる実践環境でテストされ、迅速に成熟していきます。 ブルームーンが出現するのと同じくらい稀な条件が、企業のデータセンターで起こっても、すぐにテストされ、本番システムで問題が起こる前に対応されます。

さらに、マネージドサービスはハイレベルのAPIという形で公開されているので、サービスのオペレーターは、APIを介して呼び出すプログラムに対してはそのインターフェースを変更することなしに、裏側では、サービスの機能を改善したり、信頼性、拡張性、機能性、および耐久性を向上させるような、変更を自由に行うことができます。

CloudSearchの基本
マネージドサービスそのものについての話は、これくらいにして、ウェブサイトやドキュメントの検索においてこれが何を意味するのかを見ていきましょう。

CloudSearchは、全ての複雑さと全ての検索インフラを隠します。やるのは、CloudSearchに検索したいドキュメント一式を提供し、どのようにアプリケーションに検索を統合するかを決めることだけです。サービスの裏側では、CloudSearchは、受け取るドキュメントを保持するのに十分な容量のストレージと、インデックスと検索リクエストを処理するのに十分な計算処理能力を確保するために、必要に応じて、検索インスタンスをを追加したり削除したりします。

独自のインデックス作成、クエリ解析、クエリ処理、結果のハンドリング、といった処理を記述する必要はありません。ディスクスペースが足りなくなったり、処理能力が足りなくなることを心配する必要もありません。機能を追加するためにコードを書き直し続ける必要さえもなくなります。

CloudSearchを使えば、アプリケーションレイヤーに集中することができます。ドキュメントをアップロードすると、CloudSearchがそれらをインデックス化しますので、お客様が必要とするカスタマイズされた検索体験をすぐに構築し始めることができます。

CloudSearchは非常に簡単に使えます。Search Domainを作成および設定し、ドキュメントをアップロード、インデックス化し、検索を実行するだけです。これらの操作は全て、CloudSearchのコンソール、コマンドライン、CloudSearch APIsを介して行うことができます。

新機能
冒頭でお話したように、CloudSearchに非常にたくさんの新機能を追加しました。詳しく見ていきましょう:

フィールドタイプ - オリジナルのフィールドタイプに加えて、単一または複数(配列)のdate、double、integer、text、literalをインデックス化および検索することが出来るようになりました。位置情報(latlon)についてもインデックス化および検索することができます。:

他言語対応 - CloudSearchは日本語を含む33の異なる言語（アラビア語、アルメニア語、バスク語、ブルガリア語、カタロニア語、簡体字中国語、繁体字中国語、チェコ語、デンマーク語、オランダ語、英語、フィンランド語、フランス語、ガリシア語、ドイツ語、ギリシャ語、ヒンディー語、ハンガリー語、インドネシア語、アイルランド語、イタリア語、日本語、韓国語、ラトビア語、ノルウェー語、ペルシャ語、ポルトガル語、ルーマニア語、ロシア語、スペイン語、スウェーデン語、タイ語、トルコ語）を語幹解釈とテキスト分析も含めて、処理できるようになりました。 別々のフィールドに1つ以上の異なる言語のドキュメントを送ることができますし、複数の言語を含んだ一つのフィールドを処理するテキストプロセッサーもあります。

強化された検索 - CloudSearchに次の新しい検索機能が追加されました。:

• 近接検索 (Proximity Search)
• 項目ブースト (Term Boosting)
• 全てのフィールドタイプでの範囲検索(Range Searching)
• 全一致のクエリ (Match-All Queries)
• 複数の設定可能なクエリパーサー (シンプルで構造かされたLuceneおよびDisMax)
• 部分検索結果 (Partial Search Results)

位置情報クエリ - 地理的な位置を表現するためにlatlon (緯度 / 経度)を使うことが出来ます。 境界ボックス(北東と南西を角を指定)内を検索したり、新しく追加されたhaversin機能を使って、2点間の大圏距離によってソートされた結果を取得したりすることもできます。

オートコンプリート、検索候補のサポート - CloudSearchは、フィールドのプレフィックス一致に基づいて、正確またはあいまいな検索語候補を生成することができます。:

ハイライト - CloudSearchは、マッチしたドキュメントのどの部分に検索項目が含まれているのかを示すために、検索結果と一緒に抜粋(プレーンテキストかHTML)を返すことができます。:

強化された可能性 - 可能性を高めるために、Multi-AZ構成でCloudSearchを実行することができるようになりました。 マネージドサービスとして、CloudSearchは必要に応じて、自動的に検索インスタンスを起動します。クエリーは、アベイラビリティーゾーンをまたいで、負荷分散されます。アップデートは両方のゾーンの検索インスタンスに送られます。

IAMの統合 - AWS Identity and Access Management (IAM)を使って、CloudSearch Configuration APIへのアクセスを制限することで、どのアカウントがドメインを作成および削除できるのか、アクセスポリシー、インデックスオプションなどを設定できるのか、といった細かいアクセス制御行うことが出来るようになりました。

設定可能なインスタンスサイズとスケーリングオプション - 初期のインスタンスサイズとインデックス複製因子を制御できるようになりました。2GB以上のソースデータを含むデータセットからスタートする場合は、m1.large以上のインスタンスを選択することをオススメします。:

CloudSearchの使い方
CloudSearchについてさらに詳しく学ぶために、Search Domainを作成し、このブログから1900の記事（2004年から現在まで)をアップロードしてみました。その際にやったことは次の通りです。

まずCloudSearchのコンソールを開き、aws-blog-postsというsearch domainを作成しました:

それから、サンプルHTMLドキュメントをアップロードし、インデックスを設定しました。CloudSearchは様々な異なるドキュメントタイプを理解し、解析することができますので、各タイプに適切なインデックスフィールドのセットを提案します。以下は今回のHTMLドキュメントを設定したものです。:

CloudSearch CLIツールをダウンロードし、インストールして、ブログ記事を含むディレクトリ上で、cs-import-documentsコマンドを実行しました。:

お腹が減っていたので、chocolateを検索してみました。:

高度な検索
CloudSearchはIMDBのサンプルデータセットを持っています。このデータセットはおよそ5,000の詳細な映画の情報を含んでいます。 CloudSearchの高度な検索機能を実験するために、別のsearch domainを作成し、Upload Documentsボタンを使って、映画のデータをインポートしてみました。(CloudSearchはAmazon S3およびDynamoDBからもデータをインポートすることができます。)

まずはStar Warsを検索してみました。:

スクリーンショットでご覧いただけるように、検索結果が自動的にファセットにグループ化され、ファセットは、検索を絞り込むために使用することができます。

CloudSearchは、算術式を使って、検索結果を並べ替え、リアルタイムに結果を表示するような強力なランク比較ツールもありますので、これを使って、最適な結果を表示できるよう、順位の変更のA/Bテストを行うことができます。:

お客様の声
最後にCloudSearchを歓迎する日本のお客様の声をご紹介いたします。

スマートインサイト株式会社は特殊な業界のアプリケーション用の検索アプリケーションを開発しています。代表取締役社長の町田潔様は次のように述べています。

「AmazonのCloudSearchは私たちの主力製品SMART/InSightにとって非常に重要なものと捉えています。使った分だけ課金されるPay as you goモデルをサーチサービスに使うことにより、私たちにとって複雑なサーチシステムを運用、管理する上での負荷を取り除き、最も重要なお客様に注力することができるようになります。SMART/InSightはAWS上のサーチ機能によりデータの種類、大きさ、置かれている場所を問わず、顧客が望んでいる形でそれらをビジュアライズさせることができるようになります。私たちはこれからもCloudSearchと共に活動してまいります。」

いますぐ検索をはじめましょう！
本日のリリースの一環として、アジアパシフィック（東京）、アジアパシフィック（シドニー）、南米（サンパウロ）リージョンで、CloudSearchが利用可能になっています。

 -- Jeff;

PS - 今回の記事は非常に長いですが、それでも強力で、便利な機能の多くを省略しています。ご自身のアプリケーションでCloudSearchをご利用いただく前に、ぜひ、CloudSearchのドキュメントに一度目を通してみてください。

また、CloudSearchのウェビナー(英語)も実施いたします。このセッションでは、CloudSearchの概要、人気な利用事例の紹介、CloudSearchを自分の環境に設置する際に役立つベストプラクティスをお話したします。

---

この記事はAWSシニアエバンジェリスト Jeff BarrのAmazon Web Services Blogの記事、 Amazon CloudSearch - Even Better Searching for Less Than $100/Monthを 堀内康弘 (Facebook, Twitter)が翻訳したものです。

Amazon CloudSearch リリースから1年

Amazon CloudSearchをリリースしてから約1年が経ちました。 リリースから1年、CloudSearchは様々なユースケースであらゆる業界のお客様に採用いただいております。

CloudSearch 利用事例
オンラインでCloudSearchを利用できるいくつかの方法を紹介いたします。

最近の記事をRedditで検索:

PBS mobile video portalでDowntown Abbeyの見逃したエピソードを検索:

ManageFlitterでTwitterのトラフィックをチェック:

Snapguideでガーデニングに関するすばらしい説明書を手にいれる:

ZipListでおいしいレシピを手にいれる:

なぜ検索なのか?
これらの採用例は、現在、ローカル、ソーシャル、そしてモバイルアプリケーションにおいて検索が急速に重要な役割を持つようになってきていることを指しています。 検索により、ユーザーは、ビッグデータの山から自分が必要としている情報を取捨選択できるようになります。 すばらしい検索体験を提供することは、ユーザーとのエンゲージメントを維持することにつながり、最終的には収入の増加につながります。

CloudSearchをご利用のお客様からお聞きするフィードバックは非常に一貫しています。CloudSearchは非常に簡単にセットアップし使うことができ、料金を節約でき、パフォーマンスもすばらしい。しかも技術リソースを検索システムの開発から解放し、アプリケーションにビジネスを差別化する付加価値を与える部分に集中することができる、というものです。

この1年での機能追加
リリースから1年で、多くの強力な機能をCloudSearchに追加してきました。その中でも重要なものをいくつか紹介いたします。

ランク比較 - CloudSearchのランク比較機能は、ランク付けの式を視覚的に比較しながら変更する新しい方法を提供します。 開発者は異なるランク付けの式とフィールドの重みの組み合わせがどのように検索結果のソーティングに影響を与えるのかをすぐに確認することができます。 フィールドの重みはスライドバーを使って調整することができます。 インデックスを再構築することなしに、ランク付けの式に関する高速なA/Bテストおよび高速なイテレーションが可能です。 ランク付けの式についてのさらに詳しい情報についてはこのビデオをご覧ください。

分析 - CloudSearchは、検索の有効性とユーザーの行動への洞察を提供するために、分析レポートを追加いたしました。 メトリクス・データは検索ドメイン毎に、トータル検索回数、一致するドキュメントが見つからなかった検索回数、最も頻繁に実行される検索、検索結果として最も頻繁に返されるドキュメントを追跡することができます。

グローバル展開 - CloudSearchは米国東部（バージニア北部）を超えて、米国西部（オレゴン）、米国西部（北カリフォルニア州）、アジアパシフィック（シンガポール）とEU（アイルランド）まで拡大しています。

今すぐ検索をはじめましょう!
今すぐCloudSearchを使いはじめましょう! 無償で最大30日お試しいただけます。無料トライアルプログラムの詳しい情報、参加方法については、Amazon CloudSearch Free Trialをご参照ください。 利用料金の詳細、Amazon CloudSearchをもっと詳しく知りたい方は、Amazon CloudSearch の概要をご覧ください。

CloudSearch Webinar
日本時間、4月18日 1:00 AM より、CloudSearchを紹介するウェビナーを開催いたします。参加希望の方は、こちらからご登録ください!

堀内康弘 (Facebook, Twitter)