AWS Solutions Architect ブログ

AWS Black Belt Online Seminar「BlackBelt 2017 Amazon AI 入門」の資料およびQA公開

こんにちは、パートナーソリューションアーキテクトの相澤です。

先日開催致しました AWS Black Belt Online Seminar 「Amazon AI 入門」の資料が公開されております。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

 

AWS Black Belt Online Seminar 2017 Amazon AI 入門 from Amazon Web Services Japan

 

Q1. 1ソースから複数の言語にてPollyで発話させるための翻訳部分は自分で実装するのですか？

A1: はい。Polly は翻訳サービスではありませんので、テキストはその国の言語で入力する必要がございます。

Q2. DetectLabels APIによって識別できるラベルの一覧をどこかのページなどで参照できますか？

A2: Rekognition では、一般的なカテゴリに属する数千のラベルがサポートされます。

    カテゴリには次のようなものがありますが、これらに限定されるものではありません。

    > 人とイベント: 「結婚式」、「花嫁」、「赤ちゃん」、「バースデーケーキ」、「ギタリスト」など。

    > 食べ物と飲み物: 「りんご」、「サンドイッチ」、「ワイン」、「ケーキ」、「ピザ」など。

    必要なラベルが見つからない場合は AWS カスタマーサポートからリクエストをお送りください。

    https://aws.amazon.com/support

    (参考) よくある質問 Q: Amazon Rekognition でサポートされるラベルの種類にはどのようなものがありますか?

            　   https://aws.amazon.com/jp/rekognition/faqs/#object-and-scene-detection

Q3. rekognitionのDetectLabels APIでのラベル付けですが、表示する信頼スコアの閾値のようなものはありますか？例えばリンゴのようにも梨のようにも見える画像の場合、信頼スコアがいくつ以上のラベルがレスポンスとして返ってくるのでしょうか

A3: 信頼スコアの閾値は指定可能です(最小値を指定することが可能です)。

    デフォルトでは 50 が設定されています。

    http://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/API_DetectLabels.html#API_DetectLabels_RequestSyntax

Q4. CompareFaces API の返却結果にある confidence と similarity について

A4. Similarity は類似度、Confidence は検出した矩形領域が顔であるかどうかの確からしさを意味します。

     下記に定義とリファレンスをまとめますので、ご確認ください。

     Similarity

       Level of confidence that the faces match.

       http://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/API_CompareFacesMatch.html

     Confidence

       Confidence level that the selected bounding box contains a face

       http://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/API_ComparedSourceImageFace.html

       http://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/API_ComparedFace.html

Q5. Lexのpromptを音声出力することはできますか？

A5: Preview 中の為、リリース時に仕様が変わる可能性がございますが、prompt を音声で出力することが可能です。

Q6. Rekognitionの制限事項の説明で、1人の顔の保存最大数？ の部分は、コレクションに保存できるFaceId数ということでしょうか

A6: ご認識の通りです。 ご指摘いただきありがとうございます。 合わせて資料を更新させていただきます。

Q7. LexのPromptに画像や選択オプションを表示することはできますか?

A7: Preview 中の為、仕様が変わる可能性がございますが、レスポンスカードを利用することが可能です。

     仕組み

     http://docs.aws.amazon.com/ja_jp/lex/latest/dg/howitworks-manage-prompts.html#msg-prompts-resp-card

     利用例

     http://docs.aws.amazon.com/lex/latest/dg/ex-resp-card.html

Q8. LexにおけるCloudWatchはどのような役目を果たすのですか？

A8: Preview 中の為、リリース時に仕様が変わる可能性がございますが、

     各Bot とそのバージョンごとに会話で発生したリクエストのカウントやリクエストの応答状況(latency[ms])などをメトリクスで確認いただくことが可能です。

Q9. この資料はどこかで公開されますか？

A9: はい、下記URLにて公開されております。

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-amazon-ai

Q10. Lexは日本語に対応しておりますでしょうか。対応していない場合、対応予定次期など解りましたらお教えください。

A10: 現状、英語のみの対応となります。 対応予定時期などについてはお答えすることができません。

Q11. Lexに関してですが、一つのBotに複数のIntentsを登録する際に、Intentsの上限などはあるのでしょうか

A11: はい、Bot に複数の Intents を登録することが可能です。 Intents の上限はアカウントに対して設けられております。

     > You can create up to 1,000 intents per AWS account

     “Amazon Lex Documentation (Preview)”に、制限事項がまとめられておりますので、合わせてご確認ください。

     http://docs.aws.amazon.com/ja_jp/lex/latest/dg/gl-limits.html

 

今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。

AWS Black Belt Online Seminar「AWS Code Services (CodeCommit, CodeBuild)」の資料およびQA公開

こんにちは、ソリューションアーキテクトの岡本です。

先日開催致しました AWS Black Belt Online Seminar 「AWS Code Services (CodeCommit, CodeBuild)」の資料が公開されております。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

 

AWS Black Belt Online Seminar 2017 AWS Code Services ( CodeCommit, CodeBuild ) from Amazon Web Services Japan

 

【Q&A】

Q1: 現在、Githubを使ってコードを管理しています。CodeCommitを使う事のメリットや違いがあれば教えてください

A1: AWS CodeCommit では毎月5アクティブ ユーザーまでは無料で利用することができ、50GB/月、10,000 Gitコマンドを発行可能で、リポジトリの数は無制限に作成することができます。また5ユーザーを超えても1アクティブ ユーザーごとに毎月1ドルで10GB/月、2,000 Gitコマンドの発行が可能です。AWS CodeCommitを利用することで外部に公開したくないプライベートなリポジトリを安価にご利用頂くことができます。さらにAWS CodeCommitではバイナリ〜ファイルを含む様々な形式やサイズのファイルをリポジトリに保存することが可能で、ファイル全体の容量は無制限となっています。（アクティブ ユーザーとは、その月に一度以上GitコマンドやAWS CodeCommitコンソールにアクセスしたユーザーのことです。）

Q2: codecomiitをVPCのプライベートセグメントのみ（オフィスからDirectConnect）で利用することは可能でしょうか？社内に閉じた環境での利用を想定しています。

A2: AWS CodeCommit はパブリックな接続でのみ利用可能です。通信にはHTTPSまたはSSHを利用しリポジトリには暗号化されて保存されます。

Q3: ebを利用しているのですが、これらのサービスとうまく連携させる方法はありますでしょうか

A3: 本日は詳しくご紹介できませんでしたが、AWS CodePipeline と連携してElastic Beanstalk を実行できます。またElastic Beanstalk のコマンドライン（EB CLI）を利用してAWS CodeCommitリポジトリから直接アプリケーションをデプロイすることも可能です。

Q4: 社内で jenkins や git で既に環境を整えています。移行が簡単にできますでしょうか。(gitだけははなしがありましたが)

A4: 他のGitサービスからの移行はとてもシンプルです。ローカルのGitリポジトリにクローンしたソースをAWS CodeCommit からクローンしたディレクトリにコピーしてPushするだけで移行が完了します。またAWS CodeBuildではJenkinsプラグインが提供されており、JenkinsのTaskとしてAWS CodeBuild を実行することが可能です。

Q5: CodeBuildはGithubと連携はできますか？

A5: はい、AWS CodeBuildはソース リポジトリとしてGitHubに対応しています。

Q6: 例えばGitHubとかだと、1ファイルあたりのサイズ制限があるのですが、CodeCommitにはないのでしょうか? CodeCommit で利用できるファイルサイズの制限はどの程度でしょうか？

A6: 1ファイルあたりは2GBまでとなっていますが、ファイル全体の合計サイズは無制限です。

Q7: codebuildの実行環境をVPC内に設定することは可能でしょうか。

A7: AWS CodeBuildは現時点ではVPC内で実行することはできません。

Q8: CodeBuildはWarningの場合はどうなりますか？その後の処理は止まりますか？

A8: BuildSpec.yamlで記述したコマンドのリターンコードが0以外の場合はエラーと判断し、処理が停止します。

Q9: CodeBuild で参照するブランチは、ビルドプロジェクトで設定することになるのでしょうか？

A9: はい、ビルド プロジェクトで指定します。

Q10: 静的解析を実施する場合はCodeBuildを使うイメージでしょうか？

A10: はい、AWS CodeBuildのBuildSpec.yaml内の installフェーズで静的解析を実施するために必要なコマンドやライブラリをコンテナ内にダウンロードし、BuildフェーズやPostBuildフェーズで静的解析を実行するイメージです。

AWS Black Belt Online Seminar「AWS Auto Scaling」の資料およびQA公開

こんにちは、ソリューションアーキテクト 焼尾です。

2017/3/15 に開催いたしました AWS Black Belt Online Seminar「AWS Auto Scaling」の資料を公開しました。当日ご参加いただいた皆さまからのご質問の回答とあわせて紹介させて頂きます。

 

AWS Black Belt Online Seminar 2017 Auto Scaling from Amazon Web Services Japan

 

【Q&A】

Q1. スケーリングポリシーでリクエスト数を使用する場合、スケーリングポリシーを複数（リクエスト数の段階）に応じて設定しないといけないと思いますが、こちらベストプラクティスはありますでしょうか？

A1. サービスとアプリケーションの傾向によって適切なしきい値は異なるため、お客様のサーバ1台あたりで捌けるリクエスト数を見極めていただき、適切なリクエスト数とサーバ数をマッピングして頂く必要があります。リクエスト数以外のメトリクス（CPU使用率など）で設定するのも一般的な方法です。

Q2. インターネット経由でのアクセスを禁止し、VPN経由でのアクセスのみを認めるようなセキュリティ設定の場合でもAutoScaleとELBの設定は可能でしょうか？可能な場合、注意点などあれば教えてください。

A2. Internal ELBを利用することでVPNまたはDirectConnect経由でELBにアクセスすることが可能です。ELB配下のAutoScalingGroupについては特にアクセス元環境を意識する必要はございません。

Q3. AutoScaling配下のサーバーを手動で再起動した場合は、Terminated状態に遷移するのでしょうか？

A3. ヘルスチェックの設定に依存します。例えばELBのヘルスチェックを利用し、タイムアウト、ヘルスチェック間隔、非正常の閾値を長く取っていた場合、インスタンスが再起動されてもヘルスチェックには失敗しない場合があります。この場合、AutoScalingはアクションを実行しません。Terminatedになるのはあくまでヘルスチェックに失敗したインスタンスのみになります。

Q4. Slide27-33の例で、M台の時にCPU使用率が80%を超えた場合、全体台数の10%分増加するトリガー（計算では0.台の追加、この場合は1台とみなす？）になりますがその場合、MAX台数が優先されサーバは追されないという認識であってますでしょうか？

A4. まず、PercentChangeInCapacityで動的スケーリングする場合、小数点が出た場合以下のように動作します。
o    1 より大きい値は小数点以下が切り捨てられます。たとえば、12.7 は 12 に丸められます。
o    0 と 1 の間の値は 1 に丸められます。たとえば、.67 は 1 に丸められます。
o    0 と -1 の間の値は -1 に丸められます。たとえば、-.58 は -1 に丸められます。
o    -1 未満の値は小数点以下が切り捨てられます。たとえば、-6.67 は -6 に丸められます。
　スケーリングポリシーにより追加される台数がMAX台数を超えてしまっている場合、AutoScalingはMAX台数までのみを立ち上げます。ご認識の通りASGのMAX台数を超えることはありません。

Q5. 猶予時間が短い場合、どのような問題が生じるのでしょうか.

A5. ヘルスチェックの猶予期間はインスタンスの起動～アプリケーションデプロイ～サービス組み込み、までに要する時間よりも長くとっておく必要があります。猶予期間が短い場合、インスタンスの構成が終わっていない状態でヘルスチェックが開始してしまい、結果ヘルスチェックに失敗→Terminateという動きになってしまいます。場合によってはインスタンスが追加されないことで再度アラームが起き続け、インスタンス起動～削除の無限ループに陥ってしまう可能性もあるので注意してください。

Q6. ASGインスタンス起動時にアプリのデプロイを自動的に行いたいがどのような方法がありますか?

A6. ASGインスタンスに対するデプロイ自働化方法については大きく分けて２つのパターンがあります。１つ目はアプリケーションまですべて含めたAMIを作成してしまう方法です。このやり方ではインスタンス起動後アプリデプロイにかかる時間が短くなるというメリットがあります。一方で、アプリ更新のたびにAMIを作ることになりますので、その点まで考慮したCICDパイプラインを作っておく必要があります。
２つ目の方法は起動してきたインスタンスが自分でアプリを取得しインストールする方法です。LaunchConfigurationのuserdataで、起動時に実行されるスクリプトを指定することができます。
また、CodeDeployというサービスと連携してデプロイをおこなうことも可能です。この方法についての詳しい情報は下記のドキュメントをご覧ください。
http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/auto-scaling-integ.html

Q7. Desired Capacityを変更しても最小台数にスケールインしてしまうと思うのですが、Desired Capacityを使うユースケースはどのようなものになるでしょうか？

A7. 一時的に指定台数にしたい時、例えば今すぐに、アラームに依存せずに台数を増やしたい/減らしたいといった場合に利用します。

Q8. いつもお世話になっております、途中離席してしまい聞き逃したかもしれませんが、Load Balancersが設定できると思いますけど、EC2がELBにアタッチされるタイミングを教えてください。また、Health Check TypeにEC2を設定していた場合と、ELBを設定した場合で、アタッチされるタイミングがかわりますか？よろしくお願いいたいします.

A8.ヘルスチェック方法に関わらずEC2が起動完了した後アタッチされます。インスタンス内でアプリケーションの構成が終わっているかどうかは考慮されません。そのためヘルスチェックの猶予期間を十分にとっておくようにしてください。

Q9. インスタンスの保護を有効にすると、絶対にターミネートされることはない？

A9. あくまでスケールインイベントでのターミネートのみ回避されます。インスタンスのヘルスチェックに失敗した場合や、terminate-instances コマンドなどで明示的にインスタンスを終了した場合、インスタンス保護を有効化しているインスタンスもターミネートされます。

Q10. AZでの制限のため、目的のインスタンスタイプで起動ができなかった場合はどのような稼働になりますか？（例：t2シリーズでのリソース不足）AWS側のリソース不足の場合です）

A10. 下記のエラーメッセージとともにインスタンス起動が失敗します。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/ts-as-capacity.html
 
Q11. ログをS3などへ退避する必要があるとありましたが、アップロード処理の推奨はありますでしょうか。

A11. S3 CLI/SDKを定期的に実行して転送することもできますし、fluentdやlogstashなどで転送する方法も一般的です。また、S3ではなくCloudWatch Logsに転送するのもひとつの方法です。
http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html
 
Q12. カスタムメトリクスでスケールすることはできますか？

A12. 可能です。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/policy_creating.html

Q13. 1台をメイン機として、2台目以降をオートスケールしたいという構成はどのように構成したらよいでしょうか。

A13. 例えばASGにアタッチされたELB配下にASG外のEC2インスタンスを１台アタッチしておくことでASGとは独立したインスタンスをサービスに組み込みことが可能です。
 
Q14. Blue/Green デプロイに、ASGの再作成というお話がありました。私達は、既存のASG 2つに対して 1. 非アクティブなASGのLaunchConfigの再設定を行う2. ELBにつながるアクティブなASGを切り替えるという方法を取っています。ASGごと作り変える場合とくらべてメリット・デメリットありますか。ASGの台数設定を保てるのでこちらを選択しています。

A14. 実施いただいている方法でも問題無いかと思います。重要なのはその処理を出来る限り自働化しておくことで、そのためにセッションの中ではCloudFormationを利用したリソース再作成の方法についてご紹介しました。
 
Q15. ASGにインスタンスタイプが異なる複数のインスタンスを登録しておくことは可能ですか？

A15. ASGに登録できるLaunchConfigurationは１種類のみのため、１つのASGに複数のインスタンスタイプを登録することはできませんが、１つのサービスの中に複数のインスタンスタイプを組み込みたいということであれば、１つのELB配下に複数のASGをアタッチすることで実現可能です。

Q16. スケールアウトしたEC2も同様に監視対象に組み込むケースが多いでしょうか。

A16. ケースバイケースですが、AutoScalingに対応した監視の仕組みを導入することは一般的です。例えば下記のAWS Partnerブログでは、ZabbixのAutoScaling連携の方法が紹介されていますので参考にしてください。
http://aws.typepad.com/aws_partner_sa/2016/09/opsjaws-try-ops-with-zabbix-4.html

 

今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。

AWS Black Belt Online Seminar「Amazon Chime」の資料およびQA公開

こんにちは、ソリューションアーキテクト 志村です。

2017/3/8 に開催いたしました AWS Black Belt Online Seminar「Amazon Chime」の資料を公開しました。当日ご参加いただいた皆さまからのご質問の回答とあわせて紹介させて頂きます。

AWS Black Belt Online Seminar 2017 Amazon Chime from Amazon Web Services Japan

【Q&A】

Q1. 現在無料(一部有料含みますが)で使えるものがありますがチャイムを使うメリットはありますでしょうか？ 

Amazon Chimeはフラストレーションフリーの会議、ビデオ通話、チャットを実現するサービスで、ワンクリックでのミーティングへの参加や高品質な通話、さらにActive Directoryとの連携などを特長としています。 

Q2. その他Communicationツール（WebEx、Skypeなど）とChat、Meetingなどは出来ますでしょうか？ 

現在のところ、Amazon Chime以外のツールとのチャット、ミーティングはサポートしていません。Amazon Chimeクライアント、Webブラウザ、またはIn-Room Video Systemを使用する必要があります。

Q3. Meeting ID、PersonalとOne-timeの使い分けがイマイチよくわかりませんでした。

Personal IDはユーザーごとに固有の値で、ミーティングによって変わることはありません。One time IDはミーティングのスケジュール時に生成され、毎回ちがう値となります。

Q4. Amazon Chime について顧客とのTV会議システムとしてプロジェクトIDの様なもので登録するドメインとして存在しないものを一時的に使うことは可能でしょうか？ 

一時的なMeeting IDを使用したい場合は、One Time IDを使用することができます。また、プロジェクトなどである程度の期間にわたって同じMeeting IDを使用したい場合は、ミーティングのホスト専用のメールアドレスをChimeに登録してご利用いただくことも可能です。

Q5. 複数ユーザーとチャットを行うには、チームアカウントで全員plus以上のエディションである必要があるのでしょうか？また、Slackのチャンネルのように、複数のチャットルームを作成して同時に会話することは出来ますでしょうか 

複数ユーザーでチャットはBasic/Plus/Proのすべてのエディションで可能です。また、複数のチャットルームを作成して同時に切り替えながら会話をおこなうことが可能です。

Q6. PC-WEB版でブラウザによって対応非対応はございますでしょうか？※聴き逃していたら申し訳ございません。

 ブラウザの前提条件は以下の通りです。

Internet Explorer 9/10/11およびMicrosoft Edge
Firefox 48以降
Chrome 54以降

Q7. WebでChimeを使用する場合、プラグインをインストールする必要があるでしょうか？

ブラウザにプラグインをインストールする必要はありません。

今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。

【開催報告】AWS re:Invent 2016 Security Follow Up セミナー

2016年12月21日、目黒のAmazon Web Services (AWS) Japanオフィスにて、AWS re:Invent 2016のセキュリティ関連フォローアップセミナーが開催されました。AWS re:Invent 2016とは、ラスベガスで行われたAWS最大のカンファレンスです。エンドユーザー様、パートナー様を中心に約32000人の来場者を集め、日本からも多くの方が参加されました。基調講演や各種セッション、AWSサービスのアップデート、パートナー様ソリューション展示、参加者同士のネットワーキングなどからなります。多種多様な演目と大量の情報に圧倒されたとの声も多く聞きました。

そこで本セミナーは、セキュリティという観点に絞り、re:Invent 2016での情報を効率的に収集いただくと同時に、re:Invent未参加の方にも「自分もre:Inventに行きたい！」と思ってもらえることを目的として開催しました。AWSのSolutions Architectだけでなく、re:Inventスポンサーであるパートナー様、そしてAWSに造詣の深いエンドユーザー様にご登壇いただき、re:Inventの魅力を伝えていただきました！

 

[AWSセッション] セキュリティ新サービス紹介① AWS Organizations

 最初のセッションはAWS Security Solutions Architectの桐山によるAWS Organizationsの紹介です。2017年2月27日にリリースしたばかりの新サービスで、複数のAWSアカウントの効率的な管理を実現します。AWS上で稼働するシステムの規模が大きくなるほど、開発・運用のためのAWSアカウント数も増えていきがちです。その管理をもっと簡単に行いたいと思っていたAWSユーザーにとっては、待望のサービスがリリースされたと言えるでしょう。

登壇資料はこちらです。

Aws re:Invent 2016 Security Follow Up AWS Organizations from Hayato Kiriyama

 

[AWSセッション] セキュリティ新サービス紹介② AWS Shield

続いてのセッションはAWS Solutions Architect荒木による、DDoS対策サービスAWS Shieldの紹介です。AWSがなぜDDoS対策をやり始めたかの説明からはじまり、AWSならではのメリット、そしてAWS Shieldの特徴的なサービス内容まで語られました。昨今ではDDoS攻撃がニュースを騒がせ、全ての企業にとってDDoS対策が必要となっていく中で、AWS ShieldはAWSユーザーを守る強固な盾となるでしょう。

登壇資料はこちらです。

AWS Shieldのご紹介 Managed DDoS Protection from Amazon Web Services Japan

 

[パートナー様セッション] スポンサー側から見た AWS re:Invent の醍醐味と感じたセキュリティの流れ

ここからはパートナー様セッションです。まずは、re:Inventのダイヤモンドスポンサーであるトレンドマイクロ様からです。チームの忘年会があるのも関わらず、本セミナーに駆けつけていただいた（！）南原様より、re:Inventの醍醐味を語っていただきました。

トレンドマイクロ様の展示ブースやセッション講演内容からは、AWSエコシステムの中でのトレンドマイクロ様の存在感の大きさが伺えます。特にブースに飾られた巨大な飛行機は圧巻でした。それはクラウドを安全に飛んでいく支援をすることを表した飛行機、フライトの安全を守る官制官がSecOps、会場で配っていたフライトチケットにはトレンドマイクロ製品の検証用コードが書かれていたというのも粋な計らいです。

また、ブース展示のあり方に関する日本と北米との違いを共有いただきました。海外ではブースを訪れる人は聞きにくるのではなく、自分のアイディアをぶつけに来る人が多いようです。そしてノベルティはTシャツが効果的とのこと。

最後に、南原様が感じたセキュリティの流れとして、「Security Automation」「Security for Serverless Architecture」というキーワードが今後注目です。セキュリティ担当者がクラウドの変化に追いつくための鍵がオートメーション、サーバーレスのセキュリティを考慮する際の軸は権限管理とトラフィック精査ということで、トレンドマイクロ様の今後の動向から目が離せません。

 

[パートナー様セッション] 攻撃傾向と企業が取るべきセキュリティ施策 in Las Vegas

続きまして、三井物産セキュアディレクション(MBSD)株式会社の佐藤様、大橋様にご登壇いただきました。佐藤様からはre:InventのプラチナスポンサーであるAlert Logic社のブース展示やセッション、パブクロールの楽しそうな様子が共有されました。会場ホテルに宿泊した方は、そのルームキーにAlert Logicのロゴを見つけられたはずです！英語を話すのが苦手な方向けに、日本からのツアー参加者有志によるブース回覧ツアーなど面白い取り組みもあったようです。

大橋様からは今後どのようなセキュリティが必要になるかをご紹介いただきました。セキュリティオートメーションをやるにしても、何をトリガーに行うかとなるとやはりログが必要です。センサーとなる様々な機器からログを集め分析するのが、Alert Logicの監視サービスになります。AWS環境を対象にしたSecurity Operation Center (SOC) サービスの需要が日本でも高まっている中、Alert Logicの技術を、日本ではMBSDが展開できるというのがポイントですね。

登壇資料はこちらです。

AWS re:Invent フィードバック - 攻撃傾向と企業が取るべき セキュリティ施策 in Las Vegas - from Kazumasa Ohashi

 

[エンドユーザー様セッション] ユーザーからみたre:Invent のこれまでと今後

ここからはエンドユーザー様セッションになります。AWS経験の豊富なお二人にご登壇いただきました。最初は株式会社リクルートテクノロジーズの宮崎様です。2012年の第一回re:Inventに参加してから2016年まで毎回参加している、まさにre:Invent猛者です。re:Inventにおいてセキュリティは一年おきに盛り上がるので、来年はもっと盛り上がるだろうとのこと(!?)。宮崎様の今回のセキュリティ3大ニュースである、AWS Organizationsの発表、S3のオブジェクト単位でのCloudTrail対応、AWS Config Rulesの上限緩和、をそれぞれご紹介いただきました。

現地の過ごし方としては、人が多すぎて電源取れない人には認定者ラウンジを活用し、日用品はホテル横のWalgreensで買い物というのも、経験者ならではのTipsです。re:Inventは、「現地の熱気はストリーミングでは味わえない」「会場では周りからフレンドリーに話しかけられ一人で行っても楽しめる」そして、「日々の運用で疲れていたとしてもre:Inventから帰ってくるとまたやる気がでる！」とのことで現地参加をお勧めされていました。

登壇資料はこちらです。

ユーザーからみたre:Inventのこれまでと今後 from Recruit Technologies

 

[エンドユーザー様セッション] AWS re:Invent の衝撃 ～Large Scale Violence & Security Culture Shock～

そして最後の登壇者はKDDI株式会社の大橋様です。re:Invent初参加の大橋様からはラスベガスの、そしてAWSの暴力的(!)なスケール感の大きさをお話しいただきました。とりあえずラスベガスの食事は味も費用も暴力的で、会場のスケール感を一日32000歩くらいという歩数で表現していました。

イベント内容の方では、日米のセキュリティに対する文化的な違いに触れられました。日本は、抑止予防はしっかり、検知は最低限、回復は人力。米国は、抑止予防はほぼ何もしない、検知は徹底的、回復は可能な限り自動化。とても興味深い比較です。re:Inventをきっかけに米国式に変えていこう(検知・回復に焦点)という意識変化を起こしたいとのことでした。セキュリティ運用を企業文化から変えていくミッションを持った変革者にとって、これほど参考になる体験談やメッセージはないのではないでしょうか。

「圧倒的な規模感と焦げ付きそうなユーザーの熱量は現地に行かなければ絶対に体験できない。基調講演終わった直後にインド人の集団が壁際でコーディングしだした。新しいサービスをすぐ触りたい表れ」という締めのコメントでした。

 

総じて、今回の登壇者の方のお話しを聞くと、re:Inventでは現地でしか味わえないものがあり、空気感や熱量に触れることで日本に帰ってきてからの業務にも変化をもたらすようですね。2017年のre:Inventも是非楽しみにしていてください！

こちら登壇者の集合写真です。本フォローアップセミナーにご参加いただいた皆様、登壇者の皆様、誠にありがとうございました！

 

AWS re:Invent 2016 Security Follow Up セミナーURL： https://aws.amazon.com/jp/about-aws/events/2016/securityfollowup-20161221/

ブログ執筆： AWS Security Solutions Architect 桐山 隼人

撮影協力：AWS Professional Services 畠中 亮

 

AWS Black Belt Online Seminar「Amazon Athena」の資料およびQA公開

こんにちは、ソリューションアーキテクト 焼尾です。

2017/3/1 に開催いたしました AWS Black Belt Online Seminar「Amazon Athena」の資料を公開しました。当日ご参加頂いた皆様からのご質問の回答とあわせて紹介させて頂きます。 

 

AWS Black Belt Online Seminar 2017 Amazon Athena from Amazon Web Services Japan

 

【Q&A】

Q1. 最大クエリ容量は、S3の容量要件に準拠されるのでしょうか？
 A1. そう考えていただいて問題はないですが，より現実的な制約として，実行に30分以上かかるクエリはエラーとなりますので，実質的にはこちらが最大クエリ容量に影響するとお考えいただければと思います．なお，クエリの実行時間上限は，緩和申請を行うことが可能です．
http://docs.aws.amazon.com/athena/latest/ug/service-limits.html
 
Q2. (S3に用意する)フォルダは、必須でしょうか？
A2. S3はオブジェクトストレージであるため，フォルダという概念は存在しません．DDL で指定する場合には，一般的なファイルシステムにおけるフォルダまでのパスの形（最後が"/"で終わる形）で，S3のロケーションを指定する形となります．それ以外の形式だと，エラーになります．
 
Q3. ログ解析の用途になるかと存じますが、複数のファイルを1テーブルとして取り扱い、クエリを発行することは可能でしょうか？また、CSVだけでなく、固定長テキストや、tsvなどを解析することは可能でしょうか？
A3. DDLで指定したS3のロケーションに前方一致する全てのオブジェクトが，テーブルに含まれる形となります．そのテーブルに対して，特に範囲を制限せずクエリを投げることで，それらオブジェクトはすべてスキャンされます．TSVは読み込み可能です．また固定長テキストは，正規表現を扱うSerDeを使うことで，読み込み可能となります．

Q4. QuickSightの説明でAthenaはSPICEに対応していないとの事でしたが、画面上はSPICEを選択できたと記憶しています。SPICEを選択してもインポートされないという事でしょうか？
A4. ドキュメントでは，SPICEに対応していないという記述となっておりますが，実際の挙動としてはSPICEにインポートすることが可能となっております．
 
Q5. union型はどのような型になりますでしょうか？
A5. Hive JSON SerDe のドキュメントをご参照ください．
https://github.com/rcongiu/Hive-JSON-Serde#uniontype-support-please-read-if-you-use-it
 
Q6. では、ETLはどのように行うのがオススメですか？
A6. ETLのワークロードによるので一概にはいえませんが，例えば大量のデータに対して，全データを舐めて加工整形をする場合には，EMRにてHiveやSparkを使って行っていただくか，Glueをお使いいただくのが良いかと思います．
 
Q7. アプリケーションから呼び出す方法はありますでしょうか？
A7. JDBC経由での呼び出しとなりますので，Javaアプリケーションから呼び出すことが可能です．それ以外の言語のアプリケーションの場合には，AthenaにアクセスするためにJavaでAPIを作っていただき，それ経由で呼び出しを行う形となります．
 
Q8. Amazon Kinesis Firehose を利用してCloudWatch LogsをS3に転送してそれをAthena で分析したいのですが、Kinesis Firehoseを通すと{json}{json}のように１行に複数のJSONオブジェクトが保存されるようです。このデータを効率的にAthenaで分析するにはどういった方法がありますか？？
A8. Amazon Kinesis FirehoseにはData TransformationをAWS Lambdaで行う機能がございますので，こちらを使って所望の形式に変換すると良いです.
http://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html
Amazon CloudWatch Logsからのサブスクリプションであれば、Lambda functionに渡ってくる各レコードを、Base64デコード=>gunzip=>logEventsを取り出す=>中のmessageに改行文字を追加して結合=>Base64エンコードして返り値として渡せば、FirehoseがAmazon S3にmessageを改行付きで配置してくれるので、スキーマを定義してAthenaからクエリ可能です.
 
Q9. 向いていない処理に高頻度な分析ありますが、どれくらいの頻度のことを示しているのでしょうか？
A9. Athenaの同時クエリ実行数は5という制約がありますので，それ以上の頻度でクエリが投げられる場合には向いていないといえます．
こちらも上限緩和申請をいただくことが可能です．
http://docs.aws.amazon.com/athena/latest/ug/service-limits.html
 
Q10. 向かない処理の中で、大量データを長時間処理するのには向かないとあるが、大量データとは具体的なサイズの目安はあるか
A10. クエリ実行時間の上限である，30分以内に終わらないようなデータサイズは向いていないものとなります．ただ具体的なサイズはワークロードによって異なるため，一概にこれということはできません．実際に試していただくことをお勧めします．
こちらも上限緩和申請をいただくことが可能です．
http://docs.aws.amazon.com/athena/latest/ug/service-limits.html
 
Q11. S3のファイルは最適なサイズがございますか？Hadoop/Hiveではワーカーが水平分散できるようにファイルを分割したり、逆にファイルが小さくなりすぎないような考慮が必要ですが、Athenaでも同様に考慮したほうがよろしいでしょうか？それとも、S3は読み込みはチャンクなので１つのファイルでも問題ない等ございますでしょうか？
A11. 最適なファイルサイズを一概に定義することは難しいですが，Hiveと同様に，数百MBなど，ある程度のかたまりでファイルを分割していただくことをお勧めします．最適なファイルサイズについてはクエリによっても異なりますので，実際に検証していただくことをお勧めします．また上記の前処理を行うのと合わせて，列指向フォーマットに変換していただくこともご考慮ください．
 
Q12. JDBCやBIツールからの接続について、接続元の制限方法はどのようにしたらよいでしょうか？
A12. IAMを使用することで，JDBCやBIツールから接続するIAMユーザの接続元IPを制限することが可能です．
 
Q13. S3がServer Side Encryptionの場合特別な対応は必要でしょうか？
A13. 特に対応の必要はなく，そのままクエリを実行することが可能です.
 
Q14. 型に一致しないデータは*として扱われるという理解で良いでしょうか？
A14. 型に一致しないデータが含まれる場合には，クエリがエラーとなります．
 
Q15. Amazon Mobile Analyticsのカスタムイベントが多くある出力データのクエリには適していますか？
A15. Amazon Mobile Analytics のログの場合，JSONの入れ子データとなります．スキーマさえ定義していただければ，問題なくクエリしていただくことが可能です．
入れ子になったJSONデータのスキーマ定義については，以下のブログ記事を参照ください．
https://aws.amazon.com/jp/blogs/big-data/create-tables-in-amazon-athena-from-nested-json-and-mappings-using-jsonserde/
 
Q16. 検索対象のテーブルサイズによって課金？
A16. テーブル全体のデータサイズに関わらず，実際にスキャンしたデータ量に対して課金されます．
 
Q17. CREATE TABLE 後、格納するデータの構造の変更は可能でしょうか？
A17. できません．再度テーブルを作り直していただく必要があります．
 
Q18. S3のバケットポリシーにはどのようなアクションを許可すればよろしいでしょうか
A18. マニュアルの以下の部分をご参照ください．
http://docs.aws.amazon.com/athena/latest/ug/setting-up.html
 
Q19. パーティションを指定ない状態でwhereをしてもスキャンデータは減らせるのでしょうか?whereでのスキャンデータの削減はパーティションが前提なのでしょうか？
A19. ParquetやORCなどの列指向フォーマットであれば，クエリの内容によってはメタデータ参照によるスキップの効果で，スキャン量を削減することが可能です．
 
Q20. バッチ処理は、リトライを行わないため適していないとのことですが、バッチ処理内でリトライを行う場合は、問題ありませんか？
A20. クエリの内容と処理するデータサイズによっては，再現性のある形でメモリ溢れが起こる可能性があります．
Hive等のリトライ機構が備わっているミドルウェアを使用いただくことをお勧めします．
 
Q21. クエリが自動的に並列的に実行されるとのことだが、　どのような仕組みで行っているのか。　具体的に何GBで何並列になる、というような設定はあるのか。
A21. 詳細については，Prestoのドキュメントやコードをご覧いただければと思います．

 

 

今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。

 

AWS Black Belt Online Seminar「IoT向け最新アーキテクチャパターン」の資料およびQA公開

こんにちは、ソリューションアーキテクトの岡本です。

先日開催致しました、AWSソリューションカットのオンラインセミナー「IoT向け最新アーキテクチャパターン」の資料が公開されております。QAの回答と併せてご紹介させて頂きます。

AWS Black Belt Online Seminar 2017 IoT向け最新アーキテクチャパターン from Amazon Web Services Japan

 

【Q&A】

Q1: Greengrassはsoracomと組み合わせて使えますか？

A1: Greengrassは、エッジコンピューティングのサービスになります。どのような要件を実現したいかによりますが、組み合わせることは可能だと思います。

 

Q2: GreenGrassで、Python以外の言語のサポート予定はありますか？

A2: 現時点で公開された予定はございません。

 

Q3: AWSダッシュボード上からAWS IoTを用いてIoT端末の遠隔操作等を行いたいが、どの資料を読めばよいかご教示下さい

A3: 遠隔操作などをAWS IoTの機能であるDevice Shadowを使って実施する場合ですと以下のドキュメントが有効です。

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-thing-shadows.html

上記の仕様に従い、マネジメントコンソールのShadowを操作することで操作することが可能になります。重要なポイントは、デバイス上にそのメッセージを受けて処理するアプリケーションが実行されている必要があります。

 

Q4: デバイスシャドーは、イメージ的にMQTTに近いものなのでしょうか？デバイスが接続可能になるまで、シャドー上でキューイングされる？

A4: Shadowでは、デバイスが報告した状態を管理しております。変更したい状態を受け取り、差分が生じた場合その差分情報も管理しております。デバイスが接続されたときにその差分情報などがMQTTのメッセージとして受け取ることができるような構造になります。

シーケンスなどは以下を御確認ください。

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-thing-shadows.html

 

Q5: GreenGlassとAWS IoTの組み合わせるシステム構成はあるのか教えて頂きたいです。

A5: AWS Greengrassは、Limited Previewであるため公開されている情報が限定されておりますが、AWS IoTと連携した、セキュリティ、Shadowが利用できます。従って、組み合わせてご利用いただくことができます。

https://aws.amazon.com/jp/greengrass/

 

Q6: Amazonダッシュボタンに今日紹介された機能が使われていますか？ 

A6: Amazon Dash Buttonについて公開されている情報はございません。

 

Q7: デバイス１つあたりにデバイス証明書を発行するものでしょうか？soracom beam使えばグループ単位で証明書使用して良さそうかなと思ったので、教えてください

A7: AWS IoTでは、デバイス証明書とその証明書に対するアクセスポリシをセットで利用することになります。デバイス1つ1つに証明書とポリシをアタッチすることで、きめ細やかなアクセス制御ができますし、仮に特定のデバイスからのデータ受信を拒否したいなどの制御もできます。例えば、家電とモバイルアプリケーションを紐付けるユースケースがあったときにモバイルアプリで認証した人とその人の所有する家電を紐付け、安全に通信するためのポリシを設定することも可能になります。このように、デバイス１つ１つに証明書を入れることにより、細かく制御できるようになります。もちろん、システム・サービスの要件に依存しますので必須ではありません。

 

Q8: Greengrassはデバイスがオフラインのときでもデータ蓄積ができるとのことですが、オンラインになったとき、自動的に送信されるなどの仕組みがありますか？それともユーザー側で任意にコードを書きコントロールする必要がありますか？

A8: AWS GreengrassはLimited previewであるため現時点ではお答えできません。

 

Q9: aws iot の MQTT over websocketを使った時の端末毎の認証を行う場合のベストプラクティスは、AWS STS AssumeRoleを使って共通ポリシーを設定しつつ、キー要求の際に、自クライアントIDの限定して要求することと思いましたが、正しいでしょうか？また、別の解決策はありますでしょうか？

A9: AWS IoTを利用してMQTT over websocketを使う場合は、通常のAWS 署名バージョン 4(http://docs.aws.amazon.com/ja_jp/general/latest/gr/sigv4_signing.html)を利用します。

通常は、ユーザに紐づく認証・認可を通して利用いただくことになると思います。詳細は以下を御確認ください。

http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/protocols.html