AWS Solutions Architect ブログ

【開催報告】 AWS re:Invent 2017 Security re:Cap セミナー

2017年12月14日、目黒のAmazon Web Services (AWS) Japanオフィスにて、AWS re:Invent 2017前後にて発表されたセキュリティ関連情報を振り返るセミナーが開催されました。

AWS re:Invent 2017とは、2017年11月27日から12月1日までラスベガスで開催されたAWS最大のカンファレンスです。エンドユーザー様、パートナー様を中心に、世界中から40000人以上の来場者を集めました。re:Inventは基調講演やブレイクアウトセッション、ブートキャンプ、パートナー様ソリューション展示、参加者同士のネットワーキングなどからなります。例年同様、一人では回りきれないほど大量で多種多様なイベントが行われました。

そこで本セミナーは、セキュリティという観点に絞り、re:Invent 2017での情報を効率的に収集いただくと同時に、来年以降の日本からのre:Invent参加者を増やし、re:Inventセッション登壇者を輩出する目的で開催されました。AWSソリューションアーキテクトによる新サービスアップデートに加えて、AWSに関わりの深いエンドユーザー様、パートナー様からre:Inventの魅力を伝えていただきました！

【オープニング】 AWSセキュリティ基調講演メッセージ

by AWSセキュリティソリューションアーキテクト 桐山 隼人

AWS re:Invent 2017@Las Vegasに参加した方は、本セミナー会場にいる130名強のうち10%前後でした(re:Invent3回以上経験者はわずか2名！)。ほとんどの方にとってre:Invent情報は新鮮だったのではないかと思われます。

まずは、re:Invent 2017の基調講演におけるAWSセキュリティに関するキーメッセージの紹介です。AWSのCISOであるStephen Schmidtが、基調講演で話した「AWSはSecurity Operations Center(SOC)は持っていない」という台詞に驚く方もいました。世の中の多くの人が想像するような所謂SOCは無く、ツール化と自動化を進めた結果として、今のAWSセキュリティの姿があると語っています。

AWS re:Invent 2017 Security re:Cap Key Messages from Hayato Kiriyama

AmazonのCTOであるWerner Vogelsも、「イノベーションのスピードを支えるにはセキュリティの自動化が最良のやり方だ」と語ったように、セキュリティの自動化は、AWSセキュリティの基本的なメッセージとなっています。

そのためにいくつかのセキュリティ新サービスが発表されましたので、ここからは個別セッションに入っていきましょう。 まずはIDとアクセス管理に関するセッションです。

 

【AWSセッション】セキュリティサービスアップデート① AWS Single Sign-On (SSO)

by AWSソリューションアーキテクト 辻 義一

本セミナーで最初に紹介するサービスアップデートは、re:Inventで発表されなかった(！)、その翌週発表されたAWS Single Sign-On (SSO)についてです。re:Inventで発表されなかったサービスのため、このセミナーでその詳細を知った方がほとんどだったと思います。AWSソリューションアーキテクト辻より、サービスの内容とお勧めの使い方が説明されました。

既存の認証基盤を使って、AWS管理コンソールやSAML2.0対応アプリケーションにシングルサインオンできるのは、ユーザー利便性が向上しますが、それだけではありません。複数AWSアカウントを管理しなければならない管理者にとって、誰がどこにアクセスしているかの認証ログをCloudTrailで一元的に取得できるのは管理性向上にも寄与します。

また、一ユーザーに複数のAWSアカウントをマップすることで、開発アカウントでログインして開発アカウント権限内で必要な作業をした後に、ログアウトして、次に本番アカウントでログインすることもできる、といった使い方例も紹介されました。オペレーションミス防止や統制要件を満たすためにも使える便利なサービスとなります。

登壇資料はこちらです。

AWS Re:Invent Security Recap AWS SSO from Amazon Web Services Japan

 

【エンドユーザー様セッション】re:Inventと今後のdwangoでのAWSセキュリティについて

by 株式会社ドワンゴ 鈴木 栄伍 様

続いてのセッションは株式会社ドワンゴ鈴木様による講演です。その風貌からは想像できないほど(！)、穏やかで紳士的な語り口調の鈴木様から、re:Invent現場で感じた熱気とAWSセキュリティに関する期待について述べていただきました。

ドワンゴ様では複数アカウント管理に課題感があり、少数精鋭のセキュリティチームで効率的にセキュリティ統制をとっていく方法を模索されています。AWS Organizationsを使ってAWSアカウント管理を統一化をしつつ、既存認証基盤(Active Directory)連携できるAWS SSOでの更なる効率化を検討されるようです。

また、ID管理以外のセキュリティ対策強化と効率化を同時に考えるため、Amazon GuardDuty, Amazon Macie, AWS Systems Manager, Amazon Inspectorなどの連携ソリューションについても期待されていました。

登壇資料はこちらです。

 

【AWSセッション】セキュリティサービスアップデート② Amazon GuardDuty

by AWSパートナーソリューションアーキテクト 酒徳 知明

ここからは発見的統制に関連するセッションが始まります。その最新サービスがre:Invent 2017で発表された脅威検知サービスAmazon GuardDutyです。AWSパートナーソリューションアーキテクトの酒徳より、サービス詳細、提供価値、使用開始の仕方、デモを含めた包括的な説明がなされました。

特に課金体系について触れた際は、Amazon GuardDutyの高機能性に対して、30日間の無料使用期間を通じてコスト対効果を判断していただきたいとのことでした。CloudTrailイベント数やVPC Flow Logs分析処理量による従量課金のため、まずは自社環境で使ってみてコスト感と機能性を把握するのが最適なやり方です。

マルチアカウントデプロイメントやマルチリージョンデプロイメントに関して、自分の身を切ることも厭わない(！)デモの実施により、参加者もAmazon GuardDutyの使い方を非常に分かりやすく理解できたのではないかと思います。

登壇資料はこちらです。

Amazon guard duty_security_recap from Tomoaki Sakatoku

 

【エンドユーザー様セッション】AWS re:Invent 2017振り返り SOCの立場からみたre:Invent

by 株式会社リクルートテクノロジーズ 安東 美穂 様

株式会社リクルートテクノロジーズでSOCに所属している安東様からは、re:Inventで体験したセキュリティイベントの共有と、SOCビジネスに活用できるAWSセキュリティサービスについてご登壇いただきました。

SOC業務として、Web商用環境監視やWAF導入支援・運用をされているということで、Amazon GuardDutyやAmazon Inspector、パートナー様が提供するAWS WAF Managed Rulesなどに高い関心を示されていました。安東様の、AWS WAFが外部ナレッジを集めていくプラットフォームになるのではないか、というコメントは大変興味深いです。

re:Invent 2017では、前述のStephen Schmidtの基調講演や、その他のセッションも聴講いただきました。セキュリティが自動化された世界では、セキュリティ担当者の求められるスキルやスタンスが変わってくるという感想をもったとのことです。また、AWSのサービス開発責任者ともお話しされ、サービスの詳細やロードマップだけでなく、開発思想を感じ取れることがre:Invent参加の醍醐味とおっしゃっていただきました。

登壇資料はこちらです。

AWS re:Invent 2017 振り返り－SOCの立場からみたre:Invent from Recruit Technologies

 

【LTセッション】by 三井物産セキュアディレクション株式会社 佐藤 裕貴 様

AWSを利用する企業は世界中にいらっしゃいますが、その中でも特にT社が好きな三井物産セキュアディレクション(MBSD)佐藤様のご登壇です。

MBSD様が日本で展開しているAlertLogic社のサービスとAmazon GuardDutyの連携や、AlertLogic社がAWS WAFに提供しているManaged Ruleの話をしていただきました。

 

【LTセッション】Security re:Cap 2017 by トレンドマイクロ株式会社 姜 貴日 様

自社の忘年会を蹴ってまで(！)、本セミナーに駆けつけていただいたトレンドマイクロ株式会社 姜 様からは、Trend Micro Deep SecurityとAmazon GuardDutyの棲み分けと連携の話、Trend Micro様がAWS WAFに提供しているManaged Ruleの話をしていただきました。

トレンドマイクロ様とAWSのパートナーシップの歴史は長いですし、両社がそれぞれ技術革新を続けることで、その連携ソリューションも大きく進化を遂げてきていることが感じられました。

登壇資料はこちらです。

Security re:Cap 2017 from Kwiil Kang

 

【LTセッション】5分で始めるAWS WAFマネージドルールによる手軽なセキュリティ対策

by AWSソリューションアーキテクト 藤倉 和明

AWSソリューションアーキテクト藤倉によるAWS WAF Managed Rulesの実践編です。  ソリューションアーキテクトならではの自分の身を切ることも厭わないデモで、AWS WAF Managed Rulesがお手軽に始められることを示しました。

登壇資料はこちらです(下画像をクリック)。

 

【クロージング】AWSセキュリティマネージドサービス

by AWSセキュリティソリューションアーキテクト 桐山 隼人

本セミナーでご紹介した新サービス、AWS SSO, Amazon GuardDuty, AWS WAF Managed Rulesは全てマネージドサービスと言えます。これからセキュリティの自動化が推進されて、イノベーションを加速させる存在となる上で、マネージドサービスの利用は欠かせません。AWS利用者にとっても、サービスレベルの向上や業務効率化のために是非AWSセキュリティのマネージドサービスをご利用いただければと思います。

AWS re:Invent 2017 Security re:Cap Key Messages from Hayato Kiriyama

最後に、AWS re:Invent 2018に日本からの参加者をもっと増やすこと、そして日本のAWSユーザー様からre:Invent登壇者を輩出することを誓って、本セミナーは幕を下ろしました。

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

AWS re:Invent 2017 Security re:Cap セミナーURL：https://connpass.com/event/73369/

ブログ執筆： AWSセキュリティソリューションアーキテクト 桐山 隼人

撮影協力：AWSソリューションアーキテクト 保里 善太、安司 仁

昨年(2016年)の開催報告ブログ：http://aws.typepad.com/sajp/2017/03/aws-reinvent-2016-security-follow-up-seminar-report.html

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

こんにちは、プロフェッショナルサービスの宮本です。

先日開催致しました AWS Black Belt Online Seminar 「Amazon Aurora with PostgreSQL」の資料を公開いたしました。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

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

AWS Black Belt Online Seminar 2017 Amazon Aurora with PostgreSQL Compatibility from Amazon Web Services Japan

【Q&A】

1. RDS for PostgreSQLのスナップショットから移行可能とのことですが、どのバージョンからでも移行可能でしょうか。

本資料のP.59に記載の通り、RDS for PostgreSQL 9.6.1 以降のバージョンからの移行がサポートされております。

下記のドキュメントも合わせてご確認ください。

DB スナップショットを使用した PostgreSQL DB インスタンスから Amazon Aurora PostgreSQL DB クラスターへのデータ移行

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/AuroraPostgreSQL.Migrating.RDSPostgreSQL.html

2. 全てのデータ型に対応していますか？

はい、PostgreSQL 9.6 でサポートされているデータ型および、RDS for PostgreSQL 9.6.3 でサポートされる拡張モジュールによって追加されているデータ型をご利用いただけます。

3. Aurora DB Clusterですが、通常のRDSのMulti-AZ + リードレプリカと異なる点は何でしょうか。

本資料のP.14,27,40,41,44 のスライドをご確認いただければと思います。

4. フェイルオーバーで復旧するのにどのくらいかかりますか？

本資料のP.30 にフェイルオーバーにおけるプロセスが記載されております。こちらにも記載されている通り、通常 30秒以内にフェイルオーバーが完了します。ですが、お客様のワークロードやDNS の伝播状況などによって異なる場合もございますので、実際に検証いただければと思います。

また、以下のドキュメントにフェイルオーバーをより高速に行うためのプラクティスが記載されておりますので、合わせてご確認ください。

Amazon Aurora PostgreSQL を使用する際のベストプラクティス

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/AuroraPostgreSQL.BestPractices.html

5. ストレージ料金を削減する目的で、容量を削除することはできますか？(容量が減った場合はどうなりますか？）

現在のところ、一度利用したストレージ容量を削減することはできません。なお、データ削除後の空き領域については、再利用されます。

6. 課金はコピーも含めた容量に基づくものでしょうか？（例えば10GBのデータの場合、60GB分が課金される？）

いえ、あくまでも使用量のみに基づきます。そのため、挙げていただいた例の場合は、10GBがストレージ料金として課金されます。

7. SSDで今までだと容量により、クレジットやIOPSの変化があったと思いますがAuroraストレージの場合はどうなりますか？

 Aurora ストレージでは、Amazon Elastic Block Store (Amazon EBS)と異なり、上記のような概念はございません。

8. calculatorのサイトで、auroraが見当たらないのですが、試算はできないでしょうか？

AWS Simple Monthly Calculator(https://calculator.s3.amazonaws.com/index.html) についてのご質問という前提で回答いたします。

上記サイト内の[Amazon RDS]をクリック後、”DB Engine and License”の選択肢より[Aurora – PostgreSQL Compatible]をご選択いただくことで試算できます。

9. vacuumやreindexはやはり必要なのでしょうか？autovacuumに任せきりで問題ないでしょうか?

基本的には、PostgreSQL と同様に考えていただければと思います。Vacuum については PostgreSQL のマニュアルでも推奨されているとおり、まずは autovacuum のご利用を検討いただくと良いかと存じます。その上で、お客様のユースケースに合わせて、autovacuum 関連のパラメータをご設定ください。24.1. 定常的なバキューム作業(外部サイト:PostgreSQL マニュアル)

https://www.postgresql.jp/document/9.6/html/routine-vacuuming.html

また、CloudWatch にてトランザクションID の監視が可能ですので、こちらも合わせてご確認ください。【AWS Database Blog】Amazon RDS for PostgreSQL でトランザクションID周回の早期検知のための実装

http://aws.typepad.com/sajp/2017/01/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql.html

最後に蛇足となりますが、reindex では、ACCESS EXCLUSIVE ロックをという排他的ロックをとります。Aurora 及びRDS for PostgreSQL 9.6.3では、拡張モジュールである pg_repack もサポートしておりますので、こちらの利用もご検討ください。

pg_repack 拡張機能の使用

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.pg_repack

10. RDS のストレージ暗号化機能を利用している場合、RDS for PostgreSQL から Aurora への移行機能がサポートされていないということですが、その場合どのように移行すればよいでしょうか？( 移行時にRDS暗号化している場合の対応はどうすればいいでしょうか？)

例えば、以下のような方策がとれるかと存じます。

RDS for PostgreSQL からpg_dump や copy文などでデータをダンプいただき、Aurora へインポートする

参考：http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html

AWS Database Migration Service を利用し、データロードを行う

11. オンプレのオラクルからAuroraPostgressに移行する際の留意点はありますか？

すべての観点における留意点を網羅しているとは限りませんが、下記の資料が参考になるかと存じます。

動画：https://www.youtube.com/watch?v=sSa4tC7eFA4

資料：https://d1.awsstatic.com/events/jp/2017/summit/slide/D3T2-2_v2.pdf

12. Amazon Aurora からRDS for PostgreSQLへの移行は可能でしょうか？

Amazon Aurora with PostgreSQL Compatibility では、PostgreSQL のクライアントツールが利用可能ですので、Aurora からpg_dump や ¥copy文などでデータをダンプいただき、そのほかのPostgreSQL へインポートいただくことは可能です。

13. 単一の重たいクエリを優先度を下げて実行することは可能ですか？（ワークロード管理）

記載いただいた機能はサポートされておりませんが、Aurora レプリカを複数作成いただき、そのうちの1台を集計など重たいクエリを行う専用のインスタンスとしていただくことでワークアラウンドになるかと存じます。その場合、レプリカへアクセスする際、リーダーエンドポイントを利用するのではなく、インスタンスエンドポイントを利用いただき、アプリケーション側でSQL をそれぞれのレプリカインスタンスに振り分けるなどの工夫が必要となります。

14. MySQL版と比べたときにコスト面などでのメリットはあるのでしょうか。

同一インスタンスタイプの料金およびストレージ料金は同じです。 

 

以上です。

AWS Black Belt Online Seminar「AWSサービスを利用したアプリケーション開発を始めよう」の資料およびQA公開

こんにちは、Technical Trainerの二條です。

先日開催致しました AWS Black Belt Online Seminar 「AWSサービスを利用したアプリケーション開発を始めよう」の資料を公開いたしました。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

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

 

AWS Black Belt Online Seminar AWSサービスを利用したアプリケーション開発を始めよう from Amazon Web Services Japan

 

【Q&A】

Q1: sdk python(boto) の低レベルapiと高レベルapiの使い分けを詳しく知りたいです。
A1: 低レベル（Client)APIはサービスの提供するRPC形式のAPIと1対1の関係となっており、サービスのすべての機能が利用可能です。またネットワーク間の呼び出しが明示的なのを好む方にも向いています。一方で、高レベル（Resource)APIは、より直感的なオブジェクト指向的な抽象化によって、よりシンプルなコーディングが可能になっています。これからAWSのサービスを利用した開発を始める場合は、利用可能であれば高レベルAPIから使い始めることをお勧めします。

Q2: (上の質問のつづきで)動作の違いはありますでしょうか。
A2: 高レベルAPIで実現できることは、すべて低レベルAPIでも実現可能です。また高レベルAPIも内部ではサービスのAPIを呼び出しているので、動作が異なるということはありません。

Q3: cloud9のEC2のベースOSはAmazonLinuxでしょうか。
A3: はい、Amazon Linuxです。

Q4: SDK はオープンソースと書かれていましたが、ライセンス形態についてそれぞれどこで確認できますか？
A4: 詳細は各SDKのLICENSEドキュメントをご参照ください。例えば、AWS SDK for Python は、Apache License, Version 2.0となっています。

Q5: yumなどで、追加のパッケージをインストールすることは可能でしょうか。
A5: はい、可能です。

Q6: cloud9を使って、s3バケットのイベント通知やAPI Gatewayからの呼び出しによるテストも可能なのでしょうか。イベントトリガーによるテストが可能であるか教えていただきたいです。
A6: AWS Cloud9でデバッグ、テストできるのはローカル環境（Cloud9環境）で実行している場合のみとなります。AWSの各種サービスのイベント発火で実行されたAWS LambdaをAWS Cloud9でテストすることはできません。

Q7: cloud9はlightsailは対応していますでしょうか。
A7: SSHのポートをオープンしていただければ既存のLinuxインスタンスにAWS CLoud9環境を構築可能です。

Q8: cloud9上で、例えばrubyでいうRSpecのようなテストは実施可能でしょうか？
A8: はい、terminalから実行可能です。

Q9: cloud9 で作成したコードを他の環境(EC2インスタンス)へデプロイすることはできますか?
A9: はい、可能です。例えば、AWS Cloud9では、gitコマンドが使えますので、AWS CodeCommitにコードをpushし、それをトリガーとしてAWS CodePipelineのパイプラインを実行し、AWS CodeDeployでEC2インスタンスにデプロイすることができます。この場合、CI/CD環境をすべてAWSで実現可能です。

Q10: Cloud9のアクセスポートは443のみですか？
A10: はい、ブラウザとAWS Cloud9の間の通信は、HTTPSのみを利用します。

以上です。

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

こんにちは、プロフェッショナルサービスの宮本です。

先日開催致しました AWS Black Belt Online Seminar 「AWS WAF」の資料を公開いたしました。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

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

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

 

【Q&A】

1. セキュリティベンダー（Impervaや、トレンドマイクロなど）のセキュリティルールなどを、WAFにインポートするような仕組み（連携）はないでしょうか？もしくは、今後の目処があれば教えていただきたい。

re:Invent 2017にてAWS WAFのマネージドルールが発表されました。

マネージドルールではAlert Logic、Fortinet、Imperva、Trend Micro、TrustWaveなど、業界をリードするセキュリティ専門家がAWS Marketplaceでマネージドのルール提供します。

詳細についてはManaged Rules for AWS WAF のページをご参照ください。

https://aws.amazon.com/jp/mp/security/WAFManagedRules/

2. block時の画面とか動作はカスタマイズできるのでしょうか？

はい。可能です。Block時の動作としては403 Forbiddenをレスポンスします。

CloudFrontの「エラーレスポンスのカスタマイズ」より、Block時の画面のカスタマイズが可能です。

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html

>6. API Gatewayへのリクエストに対する対策としてAWS WAFは使えますか

API Gatewayの前段にCloudFrontを挟むことでAWS WAFの対応が可能となります。

設置する際は必要性を検討し、設定してください。（挟むことによるレイテンシの増加、WAFによる防御の期待値　等）

CloudFrontを設定した場合でも、CloudFrontを経由せずにAPI Gatewayに直接リクエストを送る事も可能です。

この場合はCloudFrontにカスタムヘッダーをオリジン転送設定をし、オリジン側でCloudFrontを経由した事をチェックし、

直接来たリクエストについてはRejectする実装等の対策を推奨いたします。

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html

3. ELBでもAWSのELBでもWAFは使えますか？

現在(2017/12時点)CloudFrontとALBが対応しております。CLB/NLBは対応しておりません。

4. 今日の例でリクエスト課金入れずに幾らになりますか?

OWASP's Top 10テンプレートを展開すると、1つのWebACLに10個のルールが作成されます。

ウェブ ACL あたり 5 USD/月 x 1

ウェブ ACL ごとに 1 ルールあたり 1 USD/月 x 10

リクエスト課金を除いて 合計15 USD/月 となります。

5. Q&Aの前に参考サイトがあったかと思うのですが、教えていただけることは可能でしょうか。

・AWS WAF - Web アプリケーションファイアウォール

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

・AS WAF と AWS Shield アドバンスドドキュメント

http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/what-is-aws-waf.html

・Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities(blog)

https://aws.amazon.com/jp/about-aws/whats-new/2017/07/use-aws-waf-to-mitigate-owasps-top-10-web-application-vulnerabilities/

・Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities(pdf)

https://d0.awsstatic.com/whitepapers/Security/aws-waf-owasp.pdf

・AWS WAF セキュリティオートメーション

https://aws.amazon.com/jp/answers/security/aws-waf-security-automations/　

・IP Address Reputationリストを自動更新でAWS WAF IP Blacklistsとして使う方法

http://aws.typepad.com/sajp/2016/05/you-can-use-aws-waf-a-web-application-firewall-to-help-protect-your-web-applications-from-exploits-that-originate-from-grou.html

6. また、ルールセットのYMLはどうやって入手して、S3にアップロードしたら良のでしょうか？

https://aws.amazon.com/jp/about-aws/whats-new/2017/07/use-aws-waf-to-mitigate-owasps-top-10-web-application-vulnerabilities/

上記サイトをご参照ください。owasp_10_base.ymlのリンクが公開されております。

展開する際には、CloudFormationでスタックを作成時のテンプレートURLとして、ymlファイルのURLを指定してください。

 

以上です。

[AWS Black Belt Onine Seminar]Amazon Elasticsearch Service

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

先日開催致しました AWS Black Belt Online Seminar Amazon Elasticsearch Service の資料を公開いたしました。
当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

今後のAWS Black Belt Online Seminarのスケジュールは こちら です。皆様のご参加をお待ちしております。
過去の資料や、動画もこちらから視聴可能ですので、そちらもご参照ください

 

aws blackbelt amazon elasticsearch service from Amazon Web Services Japan

 

ーーーーーーーー

Q1. AZは指定する？その場合、EC2のAZと異なればAZ通信が発生するのですか？

A1. Amazon ESのドメインがデプロイされるAZはAmazon ESサービスが自動で選択しますが、
VPCアクセスを利用する場合は、どのサブネットにENIを作るかをお客様に選択していただきます
https://aws.amazon.com/jp/elasticsearch-service/pricing/

 

Q2. Elastic社も、Elasic Cloudを展開していますが、AWSが提供しているからこそ、優位点などありましたら、ご教示頂けると幸いです。
以前、Elastic Cloudを試用した際に、AWS上にElastic社が構築したサービスでしたので、個人的には違いが感じられなかったです。

A2. 様々なAWSサービスとの連携・統合であったり、フルマーネージドによる運用管理の大幅な軽減、といった点を強調される際に、特にAmazon ESが訴求できるのかと思います

 

Q3.フルマネージドということで、バージョンも管理されているかと思いますが、AWSで採用しているElasticsearchのバージョンアップは自動で行われるのでしょうか？
最近、Elastic社がElasticsearch6.0をリリースされましたが、Broken Changeが多く見られたため、今まで使えたものが使えなくなるなど、気になります。

A3. バージョンアップはお客様のマニュアル作業になります
データの互換性についても移行前にお客様ご自身で確認していただく必要があります
http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-version-migration.html

ちなみに、Amazon ESはオンラインセミナー翌日に6.0のサポートを開始しました
https://aws.amazon.com/jp/about-aws/whats-new/2017/12/elasticsearch-6-0-now-available-on-amazon-elasticsearch-service/

 

Q4. typeが廃止される方向の理由について教えてください

A4. Elasticsearchが、より効率的にデータを内部で構成できるようにするため、と理解しています
詳細な情報は下記をご参照ください
https://www.elastic.co/guide/en/elasticsearch/reference/master/removal-of-types.html

 

Q5. Replicaに書き込みが完了するまでレスポンスは返ってこないですか？

A5. Elasticsearchの書き込みの一貫性を、インデックスごとにお客様自身で設定していただけます
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-index_.html#index-wait-for-active-shards

 

Q6.スケーリング時にどのパラメーターを変更してもダウンタイムは不要ですか？

A6. ブルーグリーンデプロイメントを採用していますので、基本的にダウンタイムなくクラスターがスイッチします
ただし、変更後の設定にクラスターの規模などと矛盾がありデプロイが失敗した場合などの、失敗時にはダウンタイムが発生し得ます
http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains.html#es-managedomains-configuration-changes

 

Q5. kuromojiの辞書の更新はできるのでしょうか。

A5. 更新できません

 

Q6. データは平文で保存されるのでしょうか？暗号化する方法はありますか？

A6. ブラックベルト配信時点(2017/12/5) ではストレージレベルの暗号化はサポートしていませんでしたが、
配信2日後に、EBSおよびインスタンスストアの暗号化対応を発表いたしましたので、現在はサポートしています
https://aws.amazon.com/about-aws/whats-new/2017/12/encryption-at-rest-now-available-on-amazon-elasticsearch-service/

 

Q7. ES利用時は、利用者の環境にEBSをアタッチしたEC2を複数台作成してインデックス自体が格納されるのはEBS内という理解であっていますか？

A7. お客様用に作成されるAmazon ESドメインを構成するインスタンスにEBSをアタッチし、そのEBSをElasticsearchのストレージとして使用します
選択されたインスタンスタイプによっては、EBSではなくインスタンスストアを利用することになります
http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-ebs

以上です

 

 

 

 

[AWS Black Belt Onine Seminar] AWS Glue

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

先日開催致しました AWS Black Belt Online Seminar AWS Glue の資料を公開いたしました。
当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

今後のAWS Black Belt Online Seminarのスケジュールは こちら です。皆様のご参加をお待ちしております。
過去の資料や、動画もこちらから視聴可能ですので、そちらもご参照ください

 

AWS Black Belt - AWS Glue from Amazon Web Services Japan

 

---------

Q1　現在AWS GlueにてETLのリプレイスを検討しております。Kinesis Firehose → S3 → Glue → S3 というストリーミングETLを組む場合、AWS GlueのJobをどのようなトリガーで起動するのが良いでしょうか？

A1. 現時点ではS3からのトリガーで直接Glueのジョブをトリガーする方法は用意されていないため、S3のトリガーでLambda等に連係していただき、そこからオンデマンドのジョブを呼び出していただくのが良いと考えられます。

 

Q2　　（Q1の回答に対して追加で、）ストリーミングでS3に置かれたデータにおいては、クローラ・データカタログ等は利用せずに、ジョブの実行引数に対象ファイルを渡した上で直接S3のオブジェクトをDataFrameにするのでしょうか？それとも新しくクロールされたデータのみを対象にETLコードを書くことが可能ですか？

A2. Glueのジョブ内でクローラーが確認していない、データソースやデータターゲット（Sink）とに対して処理ｇあ可能です。つまり、上記はどちらでも可能です。一旦クロールさせてから、その結果をもとに読み取ることも可能ですし、もしくは引数を元に直截S3上のオブジェクトを読み取ることも可能です。

 

Q3　　リードレプリカのように、RDS1とRDS2のスキーマ/データを合わせたいのですが、可能でしょうか？RDS1でカラムが無くなった場合、RDS2にも反映することは可能でしょうか？

A3. カラムがなくなった事をトリガーに自動的に別のRDSの表定義を変更するという機能はありません。一般的には異機種RDBでDDLの変更を自動反映させる作業は単純ではないため、RDBネイティブのレプリケーションツールの利用をご検討ください。

 

Q4　RDS1からRDS2へデータを移行する際に、特定のカラムの値を変更することは可能でしょうか

A4.ジョブの中で任意のデータ処理をする事が可能です

 

Q5　クローリングの結果スキーマのバージョンが異なっていることがわかった際に、SNSメール通知は可能でしょうか？

A5. 現時点ではスキーマの変更時に自動でSNS通知を実行する機能はありません。

 

Q6　CrawlerのJDBC接続はVPC内通信ではなくインターネット経由のアクセスになりますか？

A6.VPC内にENIが作成され、VPC内（プライベートIPアドレス）での通信になります。

 

Q7　 DynamicFrameとDynamicFrameCollectionの違いはなんですか？

A7.DynamicFrameを集める（一塊として扱う）のがDynamicFrameCollectionクラスです。

 

Q8　 Pandasを使いたいんですが可能でしょうか？

A8.AWS GlueのジョブではPure Pythonのライブラリのみサポートしています。Pandasはライブラリ中にC言語で書かれた拡張を含むため（Pure Pythonではないため）、利用できません。

 

Q9　一般的なETL製品とAWS Glueとの棲み分けについてお聞きしたいです。

A9.AWS Glueは、Pythonコードでジョブを作成しますが、一般的なETLソリューションではGUIでコンポーネントをDrag&Dropすることでジョブを作成する事ができるため、これが最も大きな違いになります。ユーザにとってどちらの方法が生産性が高いかという点でご選択ください。また、Glueはサーバレスであり、インフラの管理負担を大幅に削減できる事も既存ETL製品との違いです。

 

Q10　　 AWS Glueを選択していただく上での提案ポイントがあれば教えていただきたいです。

A10.AWS Glueのメリットは、「ジョブ(変換)コードをPythonで書け、それをサーバレスのインフラで実行できる」事にあります。ジョブをPython(PySpark)で書けることのメリットは、オープンな言語＆フレームワークなため、既存の知識が流用しやすく、プレインなコードなのでGit等のツールでの差分管理が可能です。またサーバレスなため、日々の運用負担が低くETL負荷が増加した際にもサーバ増強等の作業をする必用がないという点もメリットです。

 

Q11　 Glueのジョブであるサーバーへアクセスさせたいのですが、IPアドレスを固定することはできますか？

A11.ジョブの実行サーバはジョブ実行毎に作成されるため、IPアドレスを固定する事はできません。

 

Q12　 ETLコードにて、ターゲットのRedshiftのテーブル定義に合わせてDynamicFrameの列順変更や列追加を行う必要がある場合、どのTransformクラスを利用するべきでしょうか？

A12.列の順序を変更する場合は、ApplyMappingクラスでソースとターゲット(Sink)のマッピングを調整することが可能です。

 

Q13　　実行しているジョブやクローラの料金モニタリングはどこで行うべきですか？

A13.料金のモニタリングは、他のサービスと同様に、Billingの機能（Billingにアラートを付ける等）で行なうことが可能です。

 

Q14　　文字エンコードの縛りはありますか？

A14.AWS Glueとして特に文字コードの規定があるわけではありませんが、PySparkをベースにしているため、ジョブ処理時には文字列がUTF-8である事を想定しています。JDBCドライバ経由でRDBを読み取った場合はJDBCドライバ内で文字コードがUTF-8に変更されるものもあります。UTF-8以外のファイル（S3上）は読み取る際に文字コードをUTF-8変換する必用があります。

 

Q15　　 DataFrameでもDynamicFrameどちらでも行える処理はどちらを利用するほうがパフォーマンスメリットがありますか？

A15.パフォーマンス上の差異については現時点でのデータはありませんが、変換のオーバヘッドは低いため、必用な処理があるほうに変換をして御利用いただくのが良いと考えられます。

 

以上です。