こんにちは、ソリューションアーキテクト小川です。
毎週水曜18:00から配信している、AWS Black Belt Tech Webinar で3/16に開催した「Cost Explorer」、3/23に開催した「Amazon CloudSearch & Amazon Elasticsearch Service」の資料が公開されております。これらの資料と併せまして、当日セミナー中に頂きましたQ&Aの回答も可能な範囲で掲載させて頂きます。
【2016/03/16:Cost Explorer - 奈良岡仁】
【Q&A】
Q1. Consolidated Billing を設定して子アカウントで RI を購入するとブレンドレートになると思いますが、全体で平準化されるため RI を買ったアカウントでは割引率が減ります。プロダクトごとに収支を計算する場合に困るのですが、何か対策方法はありますか?
A1. Detailed Billing ReportにReserved Instanceの使用状況とUnblended Rate表示されますので、こちらから集計していただくことができます。
Q2. コンソルデイトビリングを設定している場合、子アカウントで自分の分だけのコストを見ることはできないのでしょうか?
A2. 子アカウントではそのアカウントのコストのみ表示することができます。ファミリー内の他アカウントのコストは表示できません。
Q3. 一つのアカウントに各部署のEC2を稼働していますが、部署別のコストを算出が必要ですが、EC2別のコスト算出は可能でしょうか。
A3. EC2に対して各部署を示すタグを設定いただくことで可能です。例えばCost ExplorerではフィルタにこのタグとEC2-Instancesを合わせて設定することで確認いただけます。また、タグを使用する際にはコスト配分タグの設定とアクティブ化が必要になります。
http://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/cost-alloc-tags.htm
【2016/03/23:Amazon CloudSearch & Amazon Elasticsearch Service - 篠原英治】
【Q&A】
Q1. Cloudsearchのインデックス更新中に検索できないなどの弊害が発生することはありますか?
A1. CloudSearchは結果整合性モデルな分散システムです。
・ドキュメントファイルのアップロード処理
・インデクシング処理
・インデックスファイルの各ノードローカルのSolrへの反映処理
上記は非同期で動いておりますし、インデクシング中にスケールが起こったりすると、先ほどまで取得できたデータが取得できない、といったような弊害はアーキテクチャ上、起こりえると言えます。(RDBMSのようにトランザクションのような機能はございません)
Q2. Cloudsearch、Multi-AZとしてプロビジョンできるとのことですが、Cloudsearch内のインデックスデータのバックアップなどは考慮する必要はありますか?必要ない場合、データの耐久性やサービスの可用性などに関するSLAのようなものはありますか?
A2. オンラインでの可用性を担保するためMulti-AZ構成をおすすめしておりますが、インデクシングされたバイナリファイルそのものはCloudSearch内部で使用しているS3に保持しておりますので、特にバックアップ等を考慮をしていただく必要はないと考えています。
但し、SLAのようなものはございませんので、そういった点がCloudSearch導入のブロッカーになるようでしたら、いつでもインデクシングを行ってサービスを再開できるように、ご自身のS3バケット等に元データを保持していただくことをおすすめします。
Q3. Cloudsearchのデータ量について、1500万件程度のデータを検索するのは問題ないですか?
A3. 問題ないと思います。例えば↓のChatWork様の事例では数億レコードをCloudSearchに保存して検索されています。
https://aws.amazon.com/jp/solutions/case-studies/chatwork/
Q4. CloudSearchでインデクシングに必要な時間の目安はどれくらいでしょうか?
A4. アップロードファイルの上限を5MBとさせていただいておりますのは、それ以上になった場合にNear Real-Timeでのインデクシングが担保できない可能性がある、という理由でございます。つきましては、インデクシング処理そのものにかかる時間は非常に短い(数秒)と考えていただいて結構です。但し、上記Q1でお答えさせていただきましたように、各処理が非同期で動いておりますので、そういった部分で、お客さま観点でリアルタイムに見えない場合も起こりうるかとは思います。また、インスタンスタイプ/数によっても変わってきますが、高速に大量データをインデクシングする必要がある場合は、パラレルにCloudSearchにインデックスファイルのアップロードのリクエストを投げていただければと思います。
Q5. EBSボリュームを使う利点には「node障害時のリスタートでデータが引き継がれる」みたいな事もあるのですか?(エフェメラルディスクを使ったら万一nodeがクラッシュした時にデータが消える可能性がある?)
A5. Amazon Elasticsearch Serviceで使用しているElasticsearchはレプリケーションの機構を持っており、必要に応じてnumbers_of_replicasを指定していただくことでデータ消失の可能性を少なるすることが出来ると考えます。
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html
また、dedicated master nodesの設定をONにしていただくことにより、より強固なクラスタ管理を実現することができます。
http://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains.html#es-managedomains-dedicatedmasternodes
但し、replica数が0の場合にエフェメラルディスクのみを用いるということであれば、ご懸念の事態が発生しうると考えます。こちらに関しましてはEBSボリュームを使用する/しないによらず、冗長性のある構成を組まれることをおすすめしております。AmazonESにおけるEBSの考え方としては、データサイズ/コスト/クエリのレイテンシといったところになるかなと思います。
Q6. なんでEBSの最大サイズ512GBである理由はあるのでしょうか?普通には16TBだと思うのですが、制限する意味はあるのでしょうか?
A6. マネージドサービスとして、レイテンシ(タイムアウト等)や、使用するミドルウェアにとって最適なディスクサイズを考慮しております。もし、特定の業務用件で512GBでは足りない、という場合はお近くのAWS営業およびSAにコンタクトを取っていただければと思います。
Q7. CloudSearchのSuggesterみたいなものはESにもあるか?
A7. Elasticsearchの機能としてSuggesterはございます。下記をご参考になさってください。
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-suggesters.html
Q8. CloudSearchでは1 document 1MBの制限があるが、ESにも似たような制限があるか?
A8. ElasticsearchはRestなAPIで操作をすることを基本としますが、そこで使われるHTTP通信の制限がございます。Amazon Elasticsearch Serviceの各インスタンスタイプにおける上限は下記をご覧ください。
・Maximum size of HTTP request payloads
http://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/aes-limits.html
Q9. ESをIAMポリシーで保護したときに、Kibanaの利用はできるのでしょうか?
A9. 例えばIAMでIPアドレス制限を行ってKibanaの保護を行うことは可能です。
但し、Kibanaの機能やクエリごとにIAMで保護を行うことはAmazon Elasticsearch Serviceをそのまま利用することでの実現は難しいです。その場合、Kibanaの手前に認証やクエリ文字列等の制御を行うProxyサーバーをEC2上に立てるといった対応をご案内することもございます。
Q10. Cloudsearchの課金について、「1,000 件のバッチアップロードリクエストごとに 0.10 USD」とありますが、これは1000件のドキュメントデータの作成・更新・削除に関するリクエスト毎の課金になりますか?それとも、1000回のアップロード(ドキュメントデータ件数は不問)のリクエストに対しての課金になりますか?例えば、1件のドキュメントを追加するリクエストを10,000回行うのと、1000件のデータを追加するリクエストを10回行うのと、では、料金は同じですか?それとも前者のほうが料金が高くなるということですか?
A10. 『1000回のアップロード(ドキュメントデータ件数は不問)のリクエストに対しての課金』こちらです。
アップロードファイルは最大5MBになりますが、その中に何件のドキュメントがあるか?といったところは課金とは関連はございません。
Q11. Logstashの代わりにfluentdのアウトプットをElasticsearchに使用できますか?
A11. はい、可能でございます。
Logstashをセミナーの中でおすすめさせていただいた理由は、AWSのクレデンシャルを使ってセキュアにAmazon Elasticsearch Serviceにデータを投入できるプラグインがある、という理由もございます。
↓のlogstash-output-amazon_esはAmazon ESチームの人間が開発しています。
https://github.com/awslabs/logstash-output-amazon_es
FluentdのElasticsearch output pluginをご利用になる際は、IPアドレスでの制限といった形なるかと思います。
Q12. クラウドサービスはHTTP通信をつかってるのでプロトコルの差異を計算する必要があるのですか?
A12. (ご質問の意図が汲み取りきれているか、、といったところはございますが、) Elasticsearchには9300番ポートを使ってバイナリプロトコルでデータを投入できますが、
https://www.elastic.co/guide/en/elasticsearch/guide/current/_talking_to_elasticsearch.html
Amazon ESではこちらがサポートされておりません。但し、こちらの機能の開放の検討および検証はしております。また、AWSの他サービスでも、例えばElastiCacheではMemcachedのバイナリプロトコルを利用する事も可能ですし、そういった観点から、性能要件によって適切なプロトコルをご選択いただくことをおすすめします。
以上です。
今週も下記2つのWebinarを配信予定です。是非 気軽にご参加下さい。
・3/29(火) 12:00~ 【AWS初心者向けWebinar】 AWS クラウドでのVDIソリューション - 国政丈力 → お申込みページ
・3/30(水) 18:00~ 【AWS BlackBelt Tech Webinar】Amazon Lumberyard & Amazon GameLift - 森祐孝 → お申込みページ