Author: AWS Japan Staff


新機能- CloudTrailを全てのお客様に

Amazon Web Servicesをご利用の皆様に大変喜ばしいお知らせがあります。このお知らせが出来るまで辛抱強く待っていましたが、それも終わりです。

このたびAWS CloudTrailは、全てのお客様に対してあらかじめ有効にされるようになりました。

これにより、何も設定することなく過去7日間のAWSアカウント活動の可視性が提供されます。この新しい、常時有効となる機能には閲覧、検索、後述のCloudTrail Event Historyを通してのダウンロード機能が実装されています。

AWS CloudTrailの有用性をまだ得られてないお客様のために説明させてください。操作上のトラブルシューティングとレビュー、コンプライアンス、監査、セキュリティのための重要なサービスが、全てのお客様に対して提供されていることに興奮を覚えます。

AWS CloudTrailは、サポートされているAWSサービスに対するアカウント活動とイベントを記録します。

AWS CloudTrailは、あなたのAWSアカウントにおいてサポートされたAWSサービスのアカウント活動とイベントを捕捉し、Amazon Simple Storage Service(S3)、CloudWatch logsとCloudWatch Eventsにイベント・ログファイルを送ります。CloudTrailであなたはTrailを一般的につくれますし、その設定がアカウント活動とイベントの補足を可能にします。CloudTrailはまた、AWSアカウントで起こっているAPI活動に可視性を提供することによって、操作上のセキュリティ問題を分析することを可能にさせます。CloudTrailはマルチリージョン構成をサポートします。またCloudWatchとインテグレーションさせると、あなたはモニターしたいイベントのきっかけをつくることができたり、AWS Lambdaにアクティビティの記録を送るためのsubscriptionを生成するこができます。AWSコマンドラインインターフェース(CLI)、AWS Management Console、AWS SDKから、またAWSアカウントの他のAWSサービスからの呼び出しのデータの検索可能な履歴を得られることを、CloudTrailサービスを利用することは意味します。

AWS CloudTrailの主要な機能

  • Always On: 設定をする必要がなくあらかじめ全てのAWSアカウントで有効化され、全てのアカウント活動履歴の記録
  • Event History: 閲覧、検索、直近のAWSアカウント活動履歴のダウンロード
  • Management Level Events: 詳細な管理活動情報の取得、例えば、EC2例またはS3バケツの作成、削除と修正
  • Data Level Events: Amazon S3オブジェクトにおける全てのAPIアクションとAPIアクションの詳細な情報の記録
  • Log File Integrity Validation: S3バケットに格納したログファイルの完全性の検査
  • Log File Encryption: あらかじめ、S3のサーバサイド暗号化機能を用いたS3バケットによる全てのログファイルの暗号化。オプションとしてAWS Key Management Service (AWS KMS)によるログファイルの暗号化
  • Multi-region Configuration: マルチリージョンからのログファイルの送信設定

AWS CloudTrailのさらなる機能をお知りになりたい場合は、製品詳細ページに記載があります。

私の同僚であるランダル・ハントが私に思い出させてくれました。つまり、お客様の課題の解決を援助するとき、CloudTrailは重要であるということです。ほとんどのAWSの人間、例えばテクニカル・エバンジェリスト・チームに所属する我々またはソリューションアーキテクトチームに所属する人間が言うのは、何が起きているのかという詳細を調べることができるようにCloudTrailを有効化する、ということです。ですのでこのリリースで、AWSコンソールまたはAWS CLI/APIを用いてすべてのお客様がアカウント活動を見ることができる(検索機能や、全てのサポートされたAWSサービスの活動の7日間のアカウント活動履歴をダウンロードする能力を含む)ことは、驚きに値しません。

CloudTrailはあらかじめ有効化されており、すべてのお客様は、現在CloudTrailにてログを取得することができ、またEvent Historyを閲覧することが可能です。この画面はイベントを7日分見ることが出来るだけでなく、詳細な情報を見ることも可能です。

もちろんですが、直接CloudTrailログファイルにアクセスするか、監査のためにログをアーカイブしたいならば、さらにTrailを追加でき、ログファイルの送出のためにS3バケットを指定することができます。また、Trailの生成はイベントをCloudWatch LogsとCloudWatch Eventsに届けることができ、それは非常に簡単なプロセスです。

CloudTrailコンソールにログインした後に、あなたは単に「Trailの生成」ボタンををクリックするだけです。

それから、あなたはTrail名のテキストボックスにTrail名を入れ、構成をすべてのリージョンに適用するか、現在選択のリージョンにだけ適用するかをラジオボタンで選びます。

Management Event画面で、CloudTrailにどの活動を追って欲しいかについて、Read/Writeイベント・ラジオボタン・オプションを選びます。このケースでは「全て」を選びます。

次のステップは私ケースのためですが、S3オブジェクト・レベル活動を追ういたいためにS3バケツを選択します。これはオプションのステップとなります。デフォルトでは、TrailがData Eventsを記録しない点に注意してください。よって、S3オブジェクトイベント活動を追跡したい場合は、Data Eventセクションで指定するBacketのData Eventsを追跡するためにTrailを構成することができます。ここでは、私はaws-blog-tew-posts バケットを選んで、すべてのRead/Write活動を追うために、デフォルトのままとします。

CloudTrailログを格納するためのTrail設定での最終的なステップは、コンソールのStorage LocationセクションでS3 Backetを選ぶことです。Backetは新規作成もできますし、既存のBacketを選択することも可能です。ここでは、テキストボックスにaws-blog-tew-postsのBacket名を入力し新規Backet生成を選択します。また、すぐにログを見つけられるようにしたいので、Storage LocationのAdvancedセクションを開き接頭辞を加えます。Backetに格納されているログに検索条件を加えたいとき、これは最も役に立ちます。ここでは「tew-2017」という接頭辞を加えています。そのほかのAdvancedセクションの選択肢、ログファイル暗号化、イベントログファイル検査、SNS通知送信はデフォルトのままにします。

以上です。これで、Createボタンを押すだけでTrailの生成に成功しました。

 

準備は出来ていますか?

サービス製品ページCloudTrailドキュメンテーションAWS CloudTrailFAQをご覧いただけくことでAWS CloudTrailについてより多くを学ぶことができます。Trail構成の有無にかかわらず、いま一度CloudTrailサービス・コンソールに進んで見ていただき、CloudTrailイベントを捜してみてください。

全てのお客様のためのこのCloudTrailの新しい発表を楽しんでいただけましたらと思います。そうすることでこの素晴らしいサービスのメリットを享受いただけるかと思います。

Tara

翻訳は、PartnerSA市崎が担当しました。原文はこちらです。

AWS Config アップデート – S3バケットをセキュアに管理する新しいマネージド ルール

AWS ConfigはAWSリソースの構成とそれらリソースにおけるリレーションシップの管理を行います。そうすることで、必要なリソースを選択し、そのリソースの変更管理を時系列ベースで確認することが可能になります。(詳細はこちらをご確認ください。)

またAWS Config RulesはAWS Configを更に強化し、強力なルールシステムを使用してConfigを拡張し、AWSルールの「管理」コレクションと、自分で作成したカスタムルールをサポートします。(AWS Config Rulesの詳細はAWS Config Rules – Dynamic Compliance Checking for Cloud Resourcesをご確認ください)。ルール(AWS Lambda ファンクション)では、AWSリソースのあるべき姿(適切に構成されているか、コンプライアンス準拠しているか)を定義します。構成に変更が検出された際に、必要なファンクションが呼び出され、構成がコンプライアンス要求に準拠しているかの確認を行うことができます。

すでに36のルールがAWSから提供されています。下記はEC2に関連するリソースの状態を確認するルールの一例になります。

新しく追加された2つのルール

本日、S3バケットを安全にご利用頂くために、新たに2つのマネージド ルールが追加されました。これらのルールは数クリックで有効にすることが出来ます。追加された2つのルールは以下になります。

S3-bucket-public-write-prohibited:誰でも書き込みが可能に設定されているバケットを自動的に検知します。意図的に設定をするケースも稀にありますが、そうすることで悪意のあるコンテンツを誰でも書き込めるようになり、かつ既存のコンテンツも削除(上書き)をされてしまいます。このルールはアカウント内のすべてのバケットに対し適用されます。

S3-bucket-public-read-prohibited:グローバルに公開されてれいるバケットを自動的に検知します。これにより、公開されているウェブサイトやドキュメントなどのコンテンツにフラグが立てられます。 このルールは、アカウント内のすべてのバケットもチェックします。

既存のルールと同様に、スケジュールベースでの実行も可能ですし、AWS Configによる構成変更の検知をベースに実行することも可能です。

これらの評価はミリセカンドの単位で実行され、1アカウント内の100つのバケットの評価を1分以内で実行できます。その裏では、ルールは推論エンジンにより評価され、多項式時間で判定可能な最先端の制約解決手法が活用されています(P≠NP予想の解決はされず、話が異なります)。これはAWSにおいても、大きなチャレンジでAWS re:Inventのセッションでも触れられています: Automated Formal Reasoning About AWS Systems :

 

本日から利用可能です

これら2つのルールは本日よりご利用できます。既存のルールと同様に、1つのルールあたり、1ヶ月2ドルとなります。

Jeff

翻訳はPartner SA酒徳が担当しました。(本文はこちら)

 

AWS Glue – 一般提供開始

本日、AWS Glue の一般提供開始がアナウンスされました。Glue はフルマネージドでサーバレス、そして、クラウド最適化された ETL(extract, transform, load) サービスです。Glue は他の ETL サービスやプラットフォームと、いくつかのとても重要な点で違いがあります。第1に、Glue はサーバレスです — リソースのプロビジョニングや管理を行う必要はありません。ジョブ、もしくは、クローリングを実行している間に Glue が使用したリソースに対する支払いのみで利用可能です(分単位課金) 。第2に、Glue のクローラです。 Glue のクローラは、複数のデータソース、データタイプ、そして、様々な種類のパーティションを跨いで、スキーマを自動的に検出・推測することができます。クローラは生成されるスキーマを編集・版管理・クエリ実行・分析で利用するため、一元的に Data Catalog に保存します。第3に、Glue はデータを元々のフォーマットから目的のフォーマットに変換する Python で記述された ETL スクリプトを自動的に生成することができます。最後に、Glue は開発者がお気に入りのツールセットを使用して ETL スクリプトを組み立てることができるように、開発者向けのエンドポイントを作成できるようになっています 。それでは詳細を具体的に見ていきましょう!

私は開発者向けエヴァンジェリストとしての仕事の中で、飛行機での移動に多くの時間を費やします。そこで、フライトデータで何かできたらかっこいいのではと考えました。ありがたいことに、アメリカ交通統計局(Bureau of Transportations Statistics: BTS)このサイトを利用し、全てのデータを誰にでも共有してくれます。私たちは簡単にデータをダウンロードし、Amazon Simple Storage Service (S3) に保存することができます。このデータが今回の基礎データとなります。

Crawlers

まず、私たちは S3 にあるフライトデータに対して、クローラを生成する必要があります。Glue のコンソールでクローラを選択し、画面の指示に従って進めます。最初のデータソースとして s3://crawler-public-us-east-1/flight/2016/csv/を指定します(データは必要に応じて追加か可能です)。次に、”flights” データベースを作成し、各テーブルに同様の “flights” 接頭語を付けるようにします。

クローラはデータセットを調べ、様々なフォルダーからパーティション(この例の場合は、年月)やスキーマを検出し、テーブルを構成します。クローラに別のデータソースやジョブを追加することや、同じデータベースにデータを登録する別のクローラを作成することもできますが、ここでは自動生成されたスキーマを見ていきましょう。

スキーマ変更(型を BIGINT から INT に変更する)を “year” に対して実施します。その時、必要であれば2つのスキーマバージョンを比較することができます。

これで、正しくデータをパースする方法を把握したので、次はいくつか変換処理を試してみましょう。

ETL Jobs

さあ、Job用のサブコンソール画面に移動し、”Add Job” をクリックしましょう。画面の指示に従い、Job に名前、選択するデータソース、そして、テンポラリファイルを配置する S3 ロケーションを設定します。次に、”Create tables in your data target” を指定することでターゲットを追加し、ターゲットとしてParquet フォーマットで出力されるデータを配置する S3 ロケーションを指定します。

”Next” をクリックすると、Glue によって提案される様々なデータの対応関係を表示する画面に遷移します。必要に応じてカラムのマニュアル調整を行うことができます — ここでは、必要のない幾つかのカラムを “X” ボタンを使って消していきましょう。

次の画面で提供される機能が私達を私の好きなパートに誘います。これが Glue について絶対的に好きなところです。

Glue は今までに設定してきた情報に基づき、データを変換するための PySpark スクリプトを生成します。左側のダイアグラムで、ETL ジョブのフローを確認することができます。右上には、注釈付きのデータソースやターゲット、trasnsform、spigot、そしてその他機能を追加するために使えるボタン一式が見て取れます。次の画面が、”transform” をクリックすると表示されるインタフェースです。

これら変換処理のどれか、もしくは、追加データソースを追加すると、Glueはインターフェースの左側に表示されている、データフローを確認できる便利で視覚的なダイアグラムを更新します。コンソールに独自コードを直接記述し、実行することもできます。このジョブに別のジョブやスケジュールの完了時に実行されるトリガー、もしくは、オンデマンドで実行されるトリガーを追加することができます。その方法により、より多くのフライトデータを追加する際、必要なフォーマットで S3 に戻されたデータをリロードすることができます。

ここで、なぜ、コードとして ETL ジョブが保存されることがとても有益であると私が考えているかをちょっと考えてみましょう。コードはポータブルで、テスト可能で、版管理可能、そして、人が読むことができます。私達の多くは毎日コードを書いています。私達はコードに精通しており、コードを簡単に操作できます。Glue は開発者としての私に、セットアップに費やしてきた数え切れないほどの時間を節約し、私は重要なコードを得ることができます。job コンソールのパワーと多機能性について記述することに丸一日かけてしまいましたが、Glue は対応して欲しいより多くの機能を持っています。例えば、私はスクリプトを編集するコンソールが好きな一方で、多くの人々が自分たちの開発環境やツール、IDE などを好んでいることも知っています。それでは、Glue でそれらを利用する方法を確認してみましょう。

Developer Endpoints and Notebooks

開発者エンドポイントは Glue のスクリプトを開発し、テストするために利用される環境です。Glueコンソールの “Dev endpoints” に移動し、右上にある “Add endpoint” をクリックすることで設定を開始します。次に、VPC、自分自身を参照する セキュリティグループを選択し、プロビジョンするのを待ちます。

一度開発者エンドポイントがプロビジョンされると、何回かの操作と”create notebook server” をクリックすることにより、Apache Zeppelin notebook server を作成することができます。インスタンスに IAM ロールを渡し、データソースと連携するパーミッションを持っているかどうか確認します。そうすると、インタラクティブにスクリプトを開発するために、サーバーに SSH 接続できたり、notebook に接続できます。

Pricing and Documentation

ここから利用料金情報の詳細を確認することができます。Glue のクローラ、ETLジョブ、そして、開発エンドポイントは DPU(Data Processing Unit) 時間で課金されます。米国東部(バージニア北部) では、1 DPU時間のコストは 0.44 USD となります。1 DPU あたり、4vCPU と 16GB メモリを利用できます。

ここでは Glue の持っている機能の半分ほどしか説明できていないので、blog を読み終えた皆さんに、ドキュメントサービスの FAQ を読むことを推奨します。Glue はコンソールで実施できること以上の機能を提供可能なリッチでパワフルな API も持っています。

本日、新しい2つのプロジェクトもリリースします。aws-glue-libs は Glue と接続し、連携するためのユーティリティ群を提供します。aws-glue-samples repo にはETL ジョブのサンプルコードがまとめられています。

私は Glue を使うことが、データを利用して何かを始める際に必要となる時間を削減するという事実をあなたが見出すことを期待します。AWS Glue に関する別の投稿がすぐにアップされるのをご期待下さい。なぜって、私はこの新しいサービスをいじくるのをやめられないのです!

Randall

(翻訳: SA川村/SA八木,原文:https://aws.amazon.com/blogs/aws/launch-aws-glue-now-generally-available/)

AWS CloudHSM アップデート – 重要データや規制に対応することが可能で、コスト効果の高いクラウド型のハードウェアベース キーマネージメント

AWSのお客様は、AWS上で驚くほど多様なミッションクリティカルなワークロードを実行しており、その多くは機密データを処理して保管しています。 「セキュリティプロセスの概要」のホワイトペーパーで詳しく説明しているように、AWSのお客様は、データを暗号化して保護するための方法について、複数のオプションから選択が可能です。 たとえば、Amazon Relational Database Service(RDS)は、サポートされているデータベースエンジン(MySQL、SQL Server、Oracle、MariaDB、PostgreSQL、およびAurora)ごとにオプションがあり、転送中のデータの暗号化もサポートしています。

多くのお客様がAWS Key Management Service(KMS)を使用してキーを集中管理したり、AWS CloudHSMが提供するハードウェアベースの鍵管理、暗号化、復号を利用することで、重要データと規制に対応したワークロードはコンプライアンスの要求に応えることができています。(ハードウェアセキュリティモジュール(HSM)について、詳しくは、 AWS CloudHSM – Secure Key Storage and Cryptographic Operationsを参照してください)。

 

主要なCloudHSMアップデート

今日、私たちが第1世代の製品から学んだことを踏まえて、我々はCloudHSMを大幅にアップデートしました。専門的な運用ノウハウの必要性を軽減し、ハードウェアベースのキー管理の利点をより多くのユーザーに提供できるように、改良しました。改善の要約を以下に示します。

従量課金モデル – CloudHSMは、シンプルで費用対効果の高い、初期費用なしの従量課金モデルで提供します。

フルマネージド – CloudHSMはスケーラブルな管理サービスになりました。プロビジョニング、パッチ適用、高可用性、およびバックアップはすべて組み込まれています。スケジュールされたバックアップは、(HSMハードウェアだけが知っている鍵を使用して)ハードウェアからHSMの暗号化イメージを抽出し、AWS内の同一のHSMハードウェアにのみリストアできます。耐久性のために、これらのバックアップはAmazon Simple Storage Service(S3)に保存され、AWS KMSマスターキーを使用してサーバーサイドのS3暗号化を使用して再度暗号化されたセキュリティ層が追加されます。

オープンかつ互換性を考慮 – CloudHSMはオープンで標準に準拠しており、PKCS#11Java Cryptography Extension(JCE)、および、Microsoft CryptoNG(CNG)など、複数のAPI、プログラミング言語、および暗号化拡張機能をサポートしています。 CloudHSMのオープン性により、キーを(暗号化された形式で)1つのCloudHSMから別のCloudHSMに移動するプロセスをより詳細かつ簡単に制御し、他の市販のHSMとの間で移行することができます。

より安全に – CloudHSM Classic(オリジナルモデル)は、FIPS 140-2レベル2に準拠した鍵の生成と使用をサポートしています。我々は、HSMにアクセスまたは変更するための物理的な試行を検出して対応するように設計されたセキュリティー・メカニズムを備え、FIPS 140-2レベル3を段階的にサポートしています。バーチャルプライベートクラウド(VPC)内に改ざん防止を備えたHSMに対して、排他的なシングルテナントアクセスとしており、お客様のキーは保護されます。 CloudHSMは、重要な管理機能と鍵管理機能のためのクォーラム認証をサポートします。この機能を使用すると、機能にアクセスできるN個の可能なIDのリストを定義され、少なくともM人以上がアクションを承認する必要があります。また、提供するトークンを使用したマルチファクタ認証もサポートしています。

AWS-Native – アップデートされたCloudHSMはAWSに統合されており、他のツールやサービスとうまく連携します。 AWS管理コンソール、AWSコマンドラインインターフェイス(CLI)、またはAPI呼び出しを使用して、HSMのクラスタを作成および管理できます。

 

使ってみましょう

1〜32のHSMで構成されたCloudHSMクラスターを作成できます。それぞれのクラスターは、特定のAWSリージョンの別々のアベイラビリティゾーンにあります。 AZをまたいでHSMを展開することで、高可用性(組み込みロードバランシングを含む)を実現できます。また、より多くのHSMを追加すると、スループットの向上が得られます。 クラスタ内のHSMは同期して維持されます。クラスタ内の1つのHSMでタスクまたは操作を実行すると、自動的に他のHSMが更新されます。 クラスタ内の各HSMには、独自のElastic Network Interface(ENI)を持ちます。

HSMとの連携は、AWS CloudHSMクライアントを介して行われます。 これはEC2インスタンス上で実行され、証明書ベースの相互認証を使用してHSMへのセキュア(TLS)接続を作成します。

ハードウェアレベルでは、各HSMに暗号操作とキーストレージのハードウェア強制分離が含まれています。 各お客様のHSMは、専用のプロセッサコアで動作します。

 

クラスタの設定:
CloudHSM Consoleを使ってクラスタを設定しましょう。

Create clusterをクリックして、希望のVPCとその中のサブネットを選択します(必要に応じて新しいVPCやサブネットを作成することもできます)。

私は自分の設定を確認し、Createをクリックします:

数分後、クラスタが表示されますが、まだ、初期化されていません。

初期化とは、証明書署名要求(Cluster CSR)を取得することだけです。

プライベートキーを作成し、それを使用してリクエストに署名します(これらのコマンドはInitialize Clusterドキュメントからコピーされましたが、出力は省略されています)。IDはクラスタを識別します。

 

$ openssl genrsa -out CustomerRoot.key 2048
$ openssl req -new -x509 -days 365 -key CustomerRoot.key -out CustomerRoot.crt
$ openssl x509 -req -days 365 -in ID_ClusterCsr.csr   \
                              -CA CustomerRoot.crt    \
                              -CAkey CustomerRoot.key \
                              -CAcreateserial         \
                              -out ID_CustomerHsmCertificate.crt

 

次のステップでは、コンソールまたはCLIを使用して署名付き証明書をクラスタに適用します。 これが完了したら、Crypt Officer(CO)とも呼ばれるHSMの管理ユーザーのパスワードを変更して、クラスタをアクティブにすることができます。

クラスタを作成、初期化し、アクティブ化されたら、それを使ってデータを保護することができます。アプリケーションは、AWS CloudHSM SDKのAPIを使用して、キーの管理、オブジェクトの暗号化と復号化などを行うことができます。 SDKはCloudHSMクライアントへのアクセスを提供します(アプリケーションと同じインスタンスで実行します)。 クライアントは、暗号化された接続でクラスタに接続します。

 

今日から利用可能です。

新しいHSMは、米国東部(北部バージニア州)、米国西部(オレゴン州)、米国東部(オハイオ州)、およびEU(アイルランド)リージョンで現在利用可能であり、それ以外にも展開予定があります。 価格は1時間のHSMあたりで1.45ドルからです。

Jeff;

(翻訳はSA瀧澤与一が担当しました。原文はこちら

 

 

新機能 − Amazon Elastic Filesystem(EFS)で保管データの暗号化をサポート

我々は、1年と少し前にAmazon Elastic File Systemを本番ローンチしました。(詳細は Amazon Elastic File System – Production Ready in Three Regionsを確認ください)。そしてその年の後半には、Direct Connec経由でのオンプレミスアクセスを追加し、今年になって米国東部(オハイオ)、欧州(フランクフルト)、アジア・パシフィック(シドニー)リージョンでも利用可能となりました。

保管データの暗号化

本日、保管データの暗号化サポートを加えることにより、EFSがより利用しやすくなりました。ファイルシステムの作成時に、ファイルシステム上に保管するコンテンツを暗号化するための鍵を選択することが可能です。AWSが管理するビルトインの鍵、あるいは、AWS Key Management Service(KMS)を利用して自身で作成した鍵がご利用可能です。ファイルのメタデータ(ファイル名、ディレクトリ名、ディレクトリの内容)はAWSが管理する鍵で暗号化されます。どちらの暗号化の形式も、業界標準のAES−256アルゴリズムを利用して実装されています。

新しいファイルシステムを作成するときにすぐにセットアップ可能です。シンプルにビルトイン鍵(aws/elasticfilesystem)、あるいは自分の鍵を選択するだけです:

EFSが残りをすべて行います! コンソールでファイルシステムを選択することで、望みどおり暗号化されているかどうかを確認できます:

データをメタデータの暗号化には、FIPS 140-2の承認に適合した暗号化アルゴリズムが利用されます。暗号化は透過的に行われ、全体のパフォーマンスへの影響は最小限です。

AWS Identitiy and Access Management(IAM)を利用して、Customer Master Key(CMK)へのアクセスを制御することができます。CMKは、ファイルシステムへアクセスするために有効化されていなければいけません。鍵を無効化すると、新しいファイルシステムの作成に使用できなくなり、保護対象の既存のファイルシステムへのアクセスが(一定期間後)ブロックされます。詳細については、Managing Access to Encrypted File Systemsをご参照ください。

すぐにご利用可能

保管データの暗号化はEFSがサポートされている全てのリージョンでご利用可能です。追加料金は発生しません。

Jeff; (翻訳はSA布目が担当しました。原文はこちら

ASP.NET CoreとAWS CodeStarのDeep Dive

AWS CodeStar チームは最近、2つのASP.NET Coreプロジェクト テンプレートの追加を発表しました。ご存知かもしれませんが、AWS CodeStarは継続的インテグレーションと継続的デプロイメント(CI/CD)パイプラインを開発者に代わって作成し、それによって開発者は貴重な時間をインフラの構築の代わりにアプリケーションの構築に費やすことができます。新しいASP.NET Coreプロジェクトテンプレートを使用することで、.NET開発者は初日からAWSアプリケーションを構築し、展開することができます。Tara Walkerの優れたブログ記事では、AWS CodeStarでASP.NET Core アプリケーションを作成する方法について説明しています。このブログ記事では、AWS CodeStarのASP.NET Coreプロジェクトにテストを追加する方法を学ぶ中で、背後で何が起こっているのかを詳しく見ていきます。

 

Unit Test プロジェクトの追加

私たちの目標は、HelloControllerの機能を実行するシンプルなテストケースを追加することです。私はあなたが全く新しいASP.Net Core Web Service プロジェクトを持っていると仮定しています。もし、まだプロジェクトを持っていない場合は、Taraのブログ記事(上記)をたどってプロジェクトを作成することができます。ASP.NET Core Web Service テンプレートを選択していることを確認してください。ASP.NET Core for AWS CodeStarプロジェクトを作成後、Team Explorer でプロジェクト リポジトリをクローンし、AspNetCoreWebServiceソリューションをロードしたら、残りのブログ記事に沿って後を追えるようになります。Team Explorer でリポジトリをセットアップするためのガイドが必要な場合は、5月のSteve RobertのVisual StudioとCodeCommitのインテグレーションについての発表をご覧ください。

最初に、AspNetCoreWebServiceTestという名前の新しいxUnitプロジェクトをAspNetCoreWebServiceソリューションに追加します。私たちの新しいテストプロジェクトはHelloControllerクラスとJsonResultを参照するので、AspNetCoreWebServiceをプロジェクト参照として追加し、Microsoft.AspNetCore.MvcをNuGet参照として追加する必要があります。それらをテストプロジェクトに追加すると、AspNetCoreWebServiceTest.csprojに次の追加情報が表示されます。

 

<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
    ...
</ItemGroup>
...
<ItemGroup>
    <ProjectReference Include="..\AspNetCoreWebService\AspNetCoreWebService.csproj" />
</ItemGroup>

 

これにより、HelloControllerクラスを直接参照し、JsonResultを展開することができます。次のように簡単なテストケースを追加しましょう。

using System;
using Xunit;
using Microsoft.AspNetCore.Mvc;
using AspNetCoreWebService.Controllers;

namespace AspNetCoreWebServiceTest
{
    public class HelloControllerTest
    {
        [Fact]
        public void SimpleTest()
        {
            HelloController controller = new HelloController();
            var response = controller.Get("AWS").Value as Response;
            Assert.Equal(response.output, "Hello AWS!");
        }
    }
}

 

ファイル名、名前空間、クラス名、およびメソッド名を変更したことに注意してください。テストを実行し、テストが合格することを確認します。ソリューション エクスプローラで次のように表示されます。

動作するテストプロジェクトを手に入れたので、アプリケーションをデプロイする前にテストをビルドして実行するようにパイプラインを更新します。

 

AWS CodeBuildジョブの更新

最初にプロジェクトの構築方法を見てみましょう。あなた、もしくはチームのメンバーがリポジトリに変更をプッシュすると、パイプラインは自動的に最新の変更に対してビルドプロセスを開始します。このステップでは、AWS CodeBuildはビルドプロセスを実行するためにリポジトリのルートにあるbuildspec.ymlファイルを使用します。

version: 0.2
phases:
  pre_build:
    commands:
      - echo Restore started on `date`
      - dotnet restore AspNetCoreWebService/AspNetCoreWebService.csproj
  build:
    commands:
      - echo Build started on `date`
      - dotnet publish -c release -o ./build_output AspNetCoreWebService/AspNetCoreWebService.csproj
artifacts:
  files:
    - AspNetCoreWebService/build_output/**/*
    - scripts/**/*
    - appspec.yml

 

AWS CodeBuildジョブは、AWS CodeBuildに.NET Coreイメージを使用します。これには buildspec.ymlで呼び出す.NET Core SDKとCLIが含まれています。このプロジェクトは1つのWebサービスで構成されているため、1つのbuildspec.ymlファイルで十分です。プロジェクトが拡大しビルドプロセスの複雑さが増すにつれて、いずれはシェルスクリプトまたはMSBuildの.projファイルを使用してシンプルにbuildspec.ymlでscript / buildファイルを呼び出すように、ビルドプロセスを外部で駆動したいと思うかもしれません。

 

ここでは dotnet publishコマンドに注目したいと思います。この発行のステップは、すべての依存関係をパッケージ化してホストマシン上ですぐに利用できるようにするために重要です。上記のbuildspec.ymlファイルのartifactsセクションで定義されているように、AWS CodeDeployがホストにアプリケーションを配置するために使用するファイル群が、Amazon S3バケットに格納されます。scripts/**/* には、appsec.ymlが依存するすべてのスクリプトが含まれています。appsec.ymlに慣れていない方や詳細を知りたい方のために次のセクションで説明します。

前のセクションでは、AWS CodeCommitリポジトリにテストプロジェクトを追加しました。今度は、新しいテストプロジェクトをビルドするためにbuildspec.ymlを更新する必要があります。ビルド ステージの一部として、単にdotnet vstestを実行することができますが、このエクササイズではベストプラクティスに従ってビルドとテストのステージを分けて構築します。 buildspec.ymlを修正してテスト バイナリをビルドし、その成果物をAspNetCoreWebServiceTest/test_outputディレクトリに発行しましょう。

pre_build:
    commands:
        ...
        - dotnet restore AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj
post_build:
    commands:
        ...
        - dotnet publish -c release -o ./test_output AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj  
artifacts:
    files:
        ...
        - AspNetCoreWebServiceTest/test_output/**/*

 

アーティファクトとしてAspNetCoreWebServiceTest/test_output/**/* を追加したことに注意してください。実際には、これは発行されたテストバイナリをAmazon S3にアップロードするようにAWS CodeBuildサービスに指示することになります。これにより、次に作成するテスト ジョブでそれらを参照できるようになります。

 

AWS CodePipelineの更新

前のセクションでは、テストを実行するために必要なバイナリをビルドして保存するために、新しいテストプロジェクトを追加し、buildspec.ymlを修正しました。次にテストステージをパイプラインに追加する方法について説明します。まずTestステージとUnitTestアクションをコンソールからパイプラインに追加しましょう。

残りのUIも以下のパラメータで埋めます:

  • Action category: Test
  • Action name: UnitTest
  • Test provider: AWS CodeBuild
  • Create a new build project を選択
  • Project name: <プロジェクト名>-test
  • Operating system: Ubuntu
  • Runtime: .NET Core
  • Version: aws/codebuild/dot-net:core-1
  • Build specificationInsert build Commands を選択
  • Build command: dotnet vstest AspNetCoreWebServiceTest/test_output/AspNetCoreWebServiceTest.dll
  • Role nameCodeStarWorker-<プロジェクト名>-CodeBuild をリストから選択
  • Input artifacts #1 は, <プロジェクト名>-BuildArtifact をリストから選択

 

ここでの重要な情報は、ビルドコマンドです。私たちのテストジョブは前のステージでビルドされたtest.dllに対してdotnet vstestを実行します。あなたのパイプラインはこのようになります。

これでほぼ完成です!「Release Change」を押してこのパイプラインを実行すると、パイプラインのテストステージで Error Code: AccessDeniedException  のメッセージを伴って実行が失敗します。これは、AWS CodeStarサービスに新しいテストステージを実行する権限がないためです。ここではAWS CodeStarプロジェクトへの適切なアクセスを許可する方法を確認しましょう。

 

Role ポリシーの更新

AWS CodeStarプロジェクトでは、さまざまなサービスやワーカーがアプリケーションを同期、ビルド、およびデプロイするための最小限のアクセス許可のポリシーを作成します。新しいAWS CodeBuildジョブを追加したので、新しいリソースへのアクセスをCodeStarWorkerCodePipelinePolicyで許可する必要があります。この変更を行うためにIAMコンソールに移動します。 [Role]タブで、 “codebuild”キーワードを使用して検索します。ロールはCodeStarWorker- <プロジェクト名> -CodePipelineの形式である必要があります。次に、ロールにアタッチされているポリシーを編集します。以下に示します。

変更したい内容は、ポリシー内にAWS CodeBuildアクションに関連付けられている新しいcodebuildリソースである arn:aws:codebuild:us-east-1:532345249509:project/<プロジェクト名>-test を追加することです。

{
    "Action": [
        "codebuild:StartBuild",
        "codebuild:BatchGetBuilds",
        "codebuild:StopBuild"
    ],
    "Resource": [
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>"
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>-test"
    ],
    "Effect": "Allow"
}

 

以上です。AWS CodeStarプロジェクトは新しいジョブを構築するための適切な権限を持ちました。[Release Change] を押して試してみてください。

 

ASP.NET Core アプリケーションのデプロイメント

ここまでAWS CodeStarがプロジェクトをビルドしテストする方法を見てきました。このセクションでは、デプロイメントプロセスを詳しく見ていきます。AWS CodeStarプロジェクトの作成の一部として、AWS CodeStarサービスはアプリケーションをホストするAmazon EC2インスタンスを作成します。またappspec.ymlの指示に従って、そのインスタンスにデプロイメントプロセスを実行するcode-deploy-agentもインストールされます。appspec.ymlを見てみましょう。

version: 0.0
os: linux
files:
  - source: AspNetCoreWebService/build_output
    destination: /home/ubuntu/aspnetcoreservice
  - source: scripts/virtualhost.conf
    destination: /home/ubuntu/aspnetcoreservice 
hooks:
  ApplicationStop:
    - location: scripts/stop_service
      timeout: 300
      runas: root

  BeforeInstall:
    - location: scripts/remove_application
      timeout: 300
      runas: root

  AfterInstall:
    - location: scripts/install_dotnetcore
      timeout: 500
      runas: root

    - location: scripts/install_httpd
      timeout: 300
      runas: root

  ApplicationStart:
    - location: scripts/start_service
      timeout: 300
      runas: root

 

各スクリプトは、デプロイメントプロセスのさまざまなステージで実行されます:

  • install_dotnetcore – もしまだインストールされていなければ .NET Core をインストールし、最初の実行時にパッケージ キャッシュをアップデートします。これはMicrosoftのUbuntuへの.NET Coreインストールの推奨方法です。
  • install_httpd – HTTPDデーモンとmodsをインストールし、HTTPD設定ファイルを上書きしてリバースプロキシを有効化します。
  • start_service – HTTPDサービスを再起動し、既存のASP.NETアプリケーション/サービス プロセスを再起動します。
  • scripts/stop_service – HTTPDサービスを停止し、既に実行している場合、ASP.NETアプリケーション/サービスを停止します。
  • remove_application – インスタンスからデプロイされているアプリケーションを削除します。

 

インスタンス上のcode-deploy-agentは、アプリケーションのデプロイ時にこれらのフックを実行して、サービスをインストールして開始します。イベントのアクティビティはAWS CodeDeployコンソールで監視でき、EC2インスタンスから詳細なログを取得できます。インスタンスへのSSH接続を開いたら、デプロイメントログを見るために /var/log/aws/codedeploy-agentに移動してください。

 

結論

このブログ記事では、アプリケーションのパイプラインにテストステージを追加する例を使用して、AWS CodeStarのASP.NET Core プロジェクトの構築とデプロイメントを学びました。この記事がAWS CodeStarの下で完全なCI / CDシステムを提供するために、さまざまなコンポーネントとAWSサービスがどのように相互作用するかを理解する助けになることを願っています。詳細については、AWS CodeStarユーザーガイドをご覧ください。AWS CodeStarに固有の問題が発生した場合は、AWS CodeStarのトラブルシューティング ガイドを参照してください。

 

(翻訳はSA 福井が担当しました。原文はこちらです。)

 

LLAPを使用してAmazon EMRでのApache Hiveクエリをターボチャージ!

Apache Hiveは、SQLを使用してHadoopクラスタに格納された大規模なデータセットを分析するための最も一般的なツールの1つです。データアナリストやデータサイエンティストは、大きなデータのクエリ、要約、探索、および分析にHiveを使用します。

Hive LLAP(Low Latency Analytical Processing)の導入により、Hiveが単なるバッチ処理ツールであるという考え方が変わりました。 LLAPは、インテリジェントなインメモリキャッシュを使用して長期実行デーモンを使用し、バッチ指向のレイテンシを覆し、1秒未満のクエリ応答時間を提供します。

この記事では、Hive LLAPのアーキテクチャと、クエリパフォーマンスを向上させるための一般的な使用例など、Hive LLAPの概要を示します。 Amazon EMRクラスタにHive LLAPをインストールして設定し、LLAPデーモンでクエリを実行する方法を学習します。

(more…)

AWS re:Invent 2017 の準備

2017 年 11 月 27 日まであとわずか 110 日となった今、私と私の同僚は re:Invent 2017 の準備を懸命に行っています。まだブログ投稿の作成や新しい LEGO の作成は開始していませんが、非常に暫定的な発表リストを確認済みで、これからの非常に多忙な 1~2 か月に向けて既に準備中です。

これまでにないほど、より多くの会場、より大きな展示ホール、より多くのコンテンツ (1,000 以上のセッション)、ハッカソン、ブートキャンプ、ワークショップ、認定のチャンスが用意されています。Tatonka チャレンジre:PLAY パーティーといった恒例の人気行事に加えて、ブルームボール (Amazon の長期にわたる伝統行事) やオールスターフィットネスアクティビティも追加されました。

毎年、長い間ご無沙汰している知り合いからチケットを求めるぎりぎりの手紙、電話、E メールをもらいますが、すべてお断りしなければなりません (「たしか 1 年生のときに一緒でしたね」というような連絡を待っていますが、どうなるかはおわかりですね)。毎年キャパシティーは増やしていますが、多くのお客様に対して売り切れになることが予想されるため、取り残されないよう、今すぐ予約することを今一度お勧めいたします。

ベガスでお会いしましょう。

Jeff;

階層とタグによるパラメータの組織化及びAmazon EC2 Systems Manager パラメータ ストアのAmazon CloudWatchイベント

このポストはアマゾンウェブサービスのソフトウェア デベロッパーエンジニアであるLusha Zhang によって書かれました。

 

Amazon EC2 Sysmtes Mangager の一部であるパラメータストアは、平文データ(データベース文字列)または秘密情報データ(パスワード、APIキーなど)を問わず、設定データを管理するための集中化された暗号化ストアを提供します。パラメータストアはAWS CLI、API、およびSDKを介して利用できるため、AWSラムダやAmazon ECSなどのAWSサービス間でパラメータを簡単に参照できます。

 

パラメータストアのその他の記事については、以下を参照してください:

 

パラメータストアは最近、階層化サポートとパラメータのタグ付け、及びCloudWatchイベント サポートをローンチしました。これらの機能によって大規模にパラメータを組織化し、管理することが可能になりました。このポストでは、これらの新しい機能を使ってセキュリティ機能を拡張し改善する方法を示します。

 

階層化パラメータ

パラメータストアの階層化サポートによって、組織構造に基づいたパラータの構造化が可能となります。これはパラメータの編成、クエリ、および権限管理のための強力なツールを提供します。

 

一般的なDevOpsのシナリオでは、開発、ベータ、本番の異なる環境に対してソフトウェアの展開を自動化します。例えば、デプロイメント設定を作成する時に、設定を保存するためにパラメータストアを利用できます。おそらく各デプロイメント環境に最低限の健全なホスト数やパーセンテージを設定しなければならず、それらを環境ごとに異なる値でパラメータストアに保存したいと思うでしょう。

 

Step1. デプロイメント設定のパスを作成する

次のコマンドを使用して、保存するパスとパラメータを作成します:

aws ssm put-parameter --name /DeploymentConfig/Prod/FleetHealth --value 75 --type String

aws ssm put-parameter --name /DeploymentConfig/Beta/FleetHealth --value 20 --type String

 

秘密情報を専用のパスの下に構造化することもできます。例えば、

aws ssm put-parameter –-name /DeploymentConfig/Prod/Password/SQLPassword –-value <password> --type SecureString

 

 

AWS マネジメント コンソールまたはAWS CLから取得したパスごとにパラメータをフィルタすることも可能です。

aws ssm describe-parameters --parameter-filters Key=Path,Option=Recursive,Values=/DeploymentConfig/Prod

 

SecureString型パラメータの利用方法の詳細については、「Ssytem Manager パラメータについて」を参照してください。

 

Step 2. パラメータを使用してデプロイメント設定を管理する

AWS CloudFormationテンプレートを使用してデプロイメント設定を作成した場合は、次の例のように本番ステージに対するFleetHealthを設定することが可能です。

#!/bin/bash

fleetHealth=$(aws ssm get-parameter --name /DeploymentConfig/Prod/FleetHealth --query Parameter.Value)

aws cloudformation create-stack --stack-name <stack_name> --template-url <templateurl> --parameters ParameterKey=FleetHealth,ParameterValue=$fleetHealth

 

再帰フラグをを使用して、本番またはベータ環境のすべての設定パラメータを取り出すことが可能です。そして選択したパラメータを取得するために返された設定階層をパースできます。

aws ssm get-parameters-by-path --path /DeploymentConfig/Prod –-recursive

 

 

階層へのアクセスを制御する

本番およびベータ環境のデプロイメント設定のためのパラメータ階層を作成したので、パラメータへのアクセスを制限したいかもしれません。おそらく開発チームは本番環境のパラメータへはアクセスせず、ベータ環境のパラメータのみにアクセスできる必要があります。

IAMを使用して、ベータ環境のパラメータ階層へのアクセスを制御します。例えば、次のIAMポリシーはユーザーに本番環境パラメータへのアクセスを制限します。

{
"Effect": "Deny",
"Action": [
"ssm:GetParametersByPath"
],
"Condition": {
"StringEquals": {
"ssm:Recursive": [
"true"
]
}
},
"Resource":“arn:aws:ssm:<region>:<account_id>:parameter/DeploymentConfig/Prod*"
}

 

ユーザーが次のコマンドを実行すると、AccessDeniedException を受け取ることになります。

aws ssm get-parameters-by-path --path /DeploymentConfig/Prod —-recursive

 

タグ付けされたパラメータ

タグを使用するとAWSリソースを容易に管理できます。パラメータをタグ付けして、グループ化したり、クエリを行うこともできます。同じデプロイメント設定の例を使用して、タグのキー値が「Password」でタグ値が「Beta」または「Prod」のタグを追加することができます。

aws ssm add-tags-to-resource --resource-type Parameter --resource-id  /DeploymentConfig/Beta/FleetHealth --tags Key=Password,Value=Beta

 

合体されたフィルタ結果を得るために、複数のフィルターを適用することもできます。例えば、Password タグキーと再起フラグつきの /DeploymentConfig/Beta パスを適用して、パスワードに関連したベータ環境のパラメータを取得することができます。

aws ssm describe-parameters --parameter-filters Key=tag:Password Key=Path,Option=Recursive,Values=/DeploymentConfig/Beta

IAMポリシーを使用してセキュリティ アクセスを管理できます。詳細については、「System Manager パラメータのアクセス制御」を参照してください。

 

CloudWatch イベント ルールからの変更通知の取得

パラメータ ストアがCloudWatch イベントのソースになりました。パラメータが作成、更新、削除される度にLambda 関数やSNSトピックのようなCloudWatchイベント ターゲットをトリガーするようにCludWatchルールをセットアップすることができます。

次の例は、CloudWatchルールを設定して、パラメータ更新のSNSトピックをトリガする方法を示しています。詳細については、「ステップ2:SNSトピックの作成」を参照してください。パラメータの更新に関する電子メール通知をトリガーするようにSNSトピックを設定したら、ターゲットのSNSトピックに関連付けるCloudWatchルールを作成します。 イベントパターンの値を編集して、通知を発生する特定のパラメータを指定することができます。

{
  "source": [
    "aws.ssm"
  ],
  "detail-type": [
    "Parameter Store Change"
  ],
  "detail": {
    "name": [
      "/DeploymentConfig/Prod/FleetHealth",
      "/DeploymentConfig/Beta/FleetHealth"
    ],
    "operation": [
"Update",
"Delete"
    ]
  }
}

 

/DeploymentConfig/Beta/FleetHealthパラメータの値を変更すると、CloudWatchイベントがメトリックに表示されます。

その間に作成したSNSトピックがトリガーされ、emailも受信できます。

 

結論

この記事では、パラメータを管理するためのいくつかの新しいパラメータ ストアの機能:階層化、タグ付け、CloudWatch 通知について示しました。階層化パラメータを使用するとプレインテキストと秘密情報の両方について設定データの構造化とアクセス管理が容易になります。タグ付けサポートはパラメータのグループ化とクエリを容易にする別の方法を提供します。CloudWatchイベントによって、パラメータの更新の通知をタイムリーに受け取ることができます。

 

筆者について

Lusha ZhangはAmazon EC2 System Managerチームのソフトウェア開発エンジニアです。彼女はAmazon Textbook RentalsからAWS Parameter Storeまで、Amazonでさまざまな製品に取り組んできました。仕事以外では、太平洋北西部でのサーフィンだけでなく、バイオリンやピアノの演奏も楽しんでいます。

 

(翻訳はSA福井が担当しました。原文はこちらです。)

 

Amazon Connect と Amazon Lex のインテグレーション

私のお気に入りのサービス、Amazon ConnectAmazon Lex に機能強化が施されました。セルフサービスの Amazon Connect はクラウドベースのサポートセンターで、ビジネスがより良いカスタマーサービスを低コストで簡単に提供できるようにしています。Amazon Lex は、音声とテキストを使用して会話型インターフェイスを構築するためのサービスです。この 2 つのサービスを統合することで、Lex の自動音声認識 (ASR) と自然言語理解 (NLU) の性能を利用し、優れたセルフサービスエクスペリエンスを顧客に提供することができます。この統合を有効にするため、Lex チームが 8kHz の音声入力サポートを追加しました。これについては後ほど詳しくご説明します。この機能のメリットは?顧客によるリクエストの大半をボットが解決できれば、電話での待ち時間を削減し、ユーザーは時間を無駄にすることなく製品を使用することができます。

Connect または Amazon Lex の背景情報については、Jeff が過去に公開したブログ [1][2] をぜひお読みください。LEGO ファンの方は特にお楽しみいただけると思います。


では、この新しい統合の使用方法を見ていきましょう。Twitch チャンネルで構築したアプリケーションを使用して、このブログ用に内容を変更します。アプリケーションのコアでユーザーが Amazon Connect の番号を呼び出します。この番号はユーザーを Lex ボットに繋げ、AWS Lambda 関数を開始します。これは Lex のインテントをベースにしています。アプリケーションでできることは?

最良のコードエディタは何だと思いますか? 個人的には vim が好きです。コード編集を行うには最高のエディタです。私の同僚の Jeff は emacs を選んでいます。 これは素晴らしいオペレーティングシステム エディタです。もし、生まれつき指の関節が普通以上にあればの話しですが。そして同僚の Tara が選んだのは Visual Studio です。これも圧倒的に優れたエディタです。ということで、もっとも優れたエディタがどれか議論するのではなく、皆さんに投票してもらうのが良いのではないかと思います。バタフライに投票することもできますので、ご安心を。

投票に参加してみませんか?+1 614-569-4019 に電話し、あなたが最高のエディタだと思うものをお知らせください!皆さんの電話番号を保存したり、音声を録音することはありませんので、何回も vim に投票して下さって構いません。ライブで投票結果を見てみますか?  http://best-editor-ever.s3-website-us-east-1.amazonaws.com/.

さて、この仕掛けをどうやって構築したと思いますか?このブログでは各コンポーネントについて説明しますが、すでに LexLambda に触れているので、主に Amazon Connect コンポーネントについて焦点を当てることにします。ここでは、すでに皆さんが Connect インスタンスを実行中であることを前提とします。

Amazon Lex

まず Lex について説明します。まず、 VoteEditor という名前のボットを 2 つのインテントを使用して作成します。 VoteEditor に単一のスロットがあり editorConnectToAgent にはスロットがありません。editor スロットに様々なコードエディタ名を入れます (emacs は除去しておきましょうか)。

AWS Lambda

Lambda 関数も実にシンプルです。まず、Amazon DynamoDB テーブルを作成して投票結果を保存します。次に Lex (build_response) に応答するヘルパーメソッドを作成します – これでメッセージを Lex の分かりやすいレスポンス形式でラップできるようになります。後はフローロジックを特定するだけです。


def lambda_handler(event, context):
    if 'ConnectToAgent' == event['currentIntent']['name']:
        return build_response("Ok, connecting you to an agent.")
    elif 'VoteEditor' == event['currentIntent']['name']:
        editor = event['currentIntent']['slots']['editor']
        resp = ddb.update_item(
            Key={"name": editor.lower()},
            UpdateExpression="SET votes = :incr + if_not_exists(votes, :default)",
            ExpressionAttributeValues={":incr": 1, ":default": 0},
            ReturnValues="ALL_NEW"
        )
        msg = "Awesome, now {} has {} votes!".format(
            resp['Attributes']['name'],
            resp['Attributes']['votes'])
        return build_response(msg)

コードを理解できているか確認します。つまり、まだ存在しないエディタに票が入ったら、エディタに 1 票を追加するようにします。そうでなければ、そのエディタの票数を「1」増やします。エージェントのリクエストを受けたら、フローを終了してフレンドリーなメッセージを返します。どうです、簡単でしょう。後は投票結果を見るため、Lex ボットに Lambda 関数を使うように指示するだけです。次に進む前に、Lex コンソールですべて問題なく作用しているか確認することができます。

Amazon Connect

問い合わせフローで Lex ボットを使用する前に、Amazon Connect インスタンスにアクセスできるか確認します。そうするには、Amazon Connect サービスコンソールに行き、インスタンスを選択してから「問い合わせフロー」にアクセスします。ボットの追加先となる Lex のセクションが表示されます。

Amazon Connect のインスタンスが Lex ボットを呼び出せることが分かったところで、Lex ボットを含む新しい問い合わせフローを作成します。[Interact] カテゴリから [Get customer input] ウィジェットを介してフローにボットを追加します。

ウィジェットを起動すると、電話の数値キーから入力を許可するための [DTMF] タブ、または音声入力とその情報を Lex サービスに渡す [Amazon Lex] タブが表示されます。[Lex] タブを使用していくつかの事項を設定します。

様々なオプションがありますが、要するに使用したいボットを追加したり (ボットのバージョンも同様)、ボットで使用したいインテントや、ボットを紹介する小さなプロンプトを追加します (場合によっては顧客にコメントを入力するように促すなど)。

最終的にコンタクトフローは次のようになります。

実際には Lex ボットを介して多数のトランザクションをユーザーが実行できるようにする場合もあるでしょう。次に、エラーまたは ConnectToAgent のインテントで、ユーザーが実際のスタッフと対話ができるキューにユーザーを追加します。ユーザーの情報を収集し保存して、エージェントが利用できるように多機能のインターフェイスを追加します。これにより、エージェントは必要な情報をすべて把握した上でユーザーとの会話をすぐに始めることができます。

では次に Lex がサポートする 8kHz オーディオサポートの使用によるメリットについて説明します。Lex は、もともと電話から 8 kHz 入力以上の高音質でサンプルされた音声入力のみサポートしていました。現代のデジタル通信アプリケーションは、通常最低でも 16 kHz でサンプルされたオーディオ信号を使用しています。この忠実度が高いレコーディングでは「ess」(/s/) や「eff」(/f/) といった音の違いを聞き分けることができます。少なくても、そのようにオーディオ専門家は説明しています。それに比べ、電話は大幅に質の低いレコーディングを使用しています。人間と人間の耳というのは、低質の録音でも音声が何を言っているのか前後関係から把握するのに長けています (証拠は「NASA アポロのレコーディング (NASA apollo recordings)」をご覧ください)。ですから、電話のデジタルシステムは大方デフォルトで 8kHz サンプリングをセットアップに使用しています。帯域幅と忠実度において具合の良いトレードオフだと思います。電話の声がいつもと違うように聞こえるのは、そのためです。サンプリングレートの基本的な問題に加えて、携帯電話によるコールデータでは通話中に聞こえないという問題がよくあります (もしもし、聞こえますか? といった具合に)。多種多様の何千種類ものデバイスと何百社というメーカー、そして数えきれないほどの様々なソフトウェア実装があります。そこで、認識にまつわる問題はどうやって解決したらいいと思いますか?

Lex チームは、この問題への対処方法は音声入力に使用する一連のモデルを拡張し、8kHz モデルを含むことだと判断しました。8 kHz のテレフォニーオーディオサンプリングレートのサポートにより、音声認識の精度やサポートセンターとのやり取りの忠実度を高めることができます。これは、数多くのお客様が Amazon Connect をもっと利用できるようにと対応しているチームの素晴らしい努力の結果と言えるでしょう。

最後になりますが、Amazon Connect は外部開発者として使用できる PostContent エンドポイントと同じものを使うため、Amazon Connect を使用していないユーザーでも Lex で 8kHz を使用することが可能です。

以上となりますが、お楽しみいただけましたか? 詳細はいつも通り「ドキュメント (docs)」や「API リファレンス (API Reference)」をご参照ください。

Randall