Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

認知科学と学習 3: エラボレーションを使って概念の理解を強化する

このブログは、認知科学の原則を使って AWS クラウドの学習効果を高める方法に関するシリーズ記事の第 3 回(最終回)です。 このシリーズの前回と前々回では、プレゼンテーションや講義からの情報を受動的にインプットすることばかりに依存しないということが、いかに重要であるかについてを取り上げました。長期的な学習効果を強化していくためにはインプットばかりでなく、その情報を能動的に 記憶から引き出す(または思い出す) よう、セルフテストに挑戦することが大切です。またこの考え方をふまえ、 時間間隔を空けた反復学習 を実践することで、学習をより効率的かつ効果的にする方法についてもご紹介しました。 どちらの戦略でも強調されているのは、学習プロセスにおいては記憶が重要な役割を果たすということです。ある分野についてのプロフェッショナルになるためには、その分野に関する主要な概念や事実といった強固な基礎を身につけることから始める必要があります。たとえば機械学習 (Machine Learnning: ML) について言えば、そもそも特徴量エンジニアリングとは何かを知らなければ、ML モデルで特徴量エンジニアリングを実践することは不可能です。 しかしこれまでに説明してきたことを鑑みると、キーとなる情報を記憶するためにいたずらに反復学習を行うことが正しいとは限りません。情報に対する理解を深めるのに役立つテクニックがいくつかあります。そのうちの 1 つはエラボレーションと呼ばれるものです。 エラボレーションとは エラボレーションとは、学習中の新しい情報を既存の知識と関連付けていくことで、新たにインプットしている情報に詳細を付け加えていくプロセスのことです。エラボレーションのプロセスでは What (何を) 学習しているかよりも、学習中のトピックの背後にある How (どのように) や Why (なぜ) により重きを置きます。ここでは簡単な例を使って、この概念をより具体的につかんでいきましょう。 エラボレーションの実践 機械学習を例にとった場合、おそらく最初に直面するハードルの 1 つは、この分野特有の用語や概念についての語彙を理解することでしょう。そのためまず Demystifying AI/ML/DL や What is Machine Learning? といったトレーニングを受講し、そこに出てくる用語や概念について時間差学習によって小刻みにセルフテストを行います。 機械学習のタイプの違いを理解しているかを確認するセルフテストの問題の 1 つとして、たとえば以下のような問題があったとします(正解は1)。 次のうち、教師あり学習が最も適しているのはどれか答えなさい 画像内の鳥を特定する 購買傾向に基づいてある集団をより小さな集団にグループ化する データセット内の特徴量の数を減らす クレジットカード取引データ内の異常を特定し、不正としてラベル付けする この問題やその他の同様の問題に正解することはさほど難しくありません。つつまり、回答にあたって教師あり学習ついて深い理解が必要な問題とは言えません。フォローアップの問題に挑戦することでエラボレーション、つまりこのトピックに関する詳細を付け加えていきます。こうすることで、より深い理解が得られます。 以下に示すのは、この状況またはその他の同様の状況でフォローアップエラボレーションとして活用できる問題の例です。 「画像内の鳥の特定」が、どのように教師あり学習の良い例であるか説明しなさい 他の選択肢が、教師あり学習に適していないのはなぜですか 正解の選択肢に加えて、教師あり学習の適切なユースケースを他に挙げなさい 正解の選択肢が、教師なし学習の例でないのはなぜですか   エラボレーションが脳に与えるインパクト エラボレーションの問題が学習に大きな効果をもたらすメカニズムは、脳が情報を最も効果的に保存および取り出す仕組みと関連しています。長期的な観点では、脳内にある他の情報と密接に接続された情報(大きく強固に張りめぐらされたクモの巣状のニューロンをイメージしてください)は、そうでない情報、つまり他の情報との関連付けが乏しく接続の弱い状態で保存された場合と比べて、はるかに簡単に記憶から取り出せるようになります。エラボレーションの問題に取り組み、学習中のトピックに詳細を付け加える訓練を実践すると、先に述べたニューロン同士の密接な結合の形成につながります。 では、この エラボレーション の原則を AWS クラウドの学習に活用するにはどうしたらよいでしょうか。以下にいくつかのアイデアを示します。 フォローアップ問題に挑戦する。反復学習 (小テストの問題に解答する、メモカードでセルフテストをする、難しい ハンズオンラボ […]

Read More

AWS Shield の脅威ランドスケープレポートが利用可能になりました

AWS Shield は、アプリケーションの脆弱性、不正なボット、分散サービス妨害(DDoS)攻撃から AWS で実行されているアプリケーションを保護する、マネージド型脅威保護サービスです。AWS Shield の脅威ランドスケープレポート(TLR)は、AWS Shield によって検出された脅威の概要が説明されています。このレポートは、AWS のお客様に代わって保護を構築するために、脅威状況を継続的に監視、評価している AWS 脅威リサーチチーム(TRT)によって作成されたものです。これには、 AWS WAF の AWS マネージドルール や AWS Shield Advanced など、サービスのルールと緩和策が含まれています。この情報を使用して、外部の脅威に関する知識を広げ、AWS で実行されるアプリケーションのセキュリティを向上させることができます。 2020 年第 1 四半期を対象とする最新のレポートから、調査結果の一部をご紹介します。

Read More
Weekly AWS

週刊AWS – 2020/6/15週

こんにちは、AWSソリューションアーキテクトの小林です。今週も週刊AWSをお届けいたします。 今回の個人的イチオシアップデートは、やはりAWS Snowconeでしょうか。いろいろなお客様と会話していると、AWSへのデータ移行に回線を利用するのは難しいけれども、Snowball Edgeを使うのはオーバーに感じる、というご相談を頂くケースがありました。Snowconeはこういったケースにピッタリの8TBのストレージで、筐体も小型軽量ですので便利にご利用いただけるお客様が多いんじゃないかな?と期待しています。東京リージョンではまだオーダーいただけませんので、もうしばらくお待ちください。 それでは、先週の主なアップデートについて振り返っていきましょう。

Read More
AWSではじめるデータレイク

「AWSではじめるデータレイク」出版記念データレイク解説セミナーの資料公開

去年よりAWSのメンバー4名(志村、上原、関山、下佐粉)でデータレイクの基礎からアーキテクチャ、構築、運用管理までをカバーした書籍「AWSではじめるデータレイク」を執筆してきたのですが、7月出版の目処がたったことを記念して、5月末から毎週木曜にデータレイクに関するWebセミナーを開催してきました。 幸いにも大変多くの方にご参加いただくことができました。ご参加いただいた方にはあらためてお礼申し上げます。 一方で、以前の回に出られなかったので資料だけでも公開して欲しい、というご要望をたくさん頂いていました。そこで今回第1回から第3回の資料を公開させていただく事になりました。 ※ 2020/06/25更新:第4回の資料を追加公開しました

Read More

SAPワークロードにおけるコストの削減、信頼性と可用性の向上、性能の向上

AWS上でSAPを稼働しているアクティブなお客様は5,000を超えています。私たちは常に、お客様のコストを削減し、信頼性と可用性を向上し、性能を向上する方法を検討しています。このブログでは、SAPのお客様に大きな影響を与える最近の素晴らしい発表をいくつかご紹介します。

Read More

SAPワークロードで新しいレベルのアジリティーを促進: SAP Commerceを例に

長い間、オンプレミスのSAPプロジェクトでは、リスクを最小限にするために、多くの前もっての要求分析、評価、サイジングプロセスが必要でした。実際に、私たちは、数週間かけた計画の後で初期の決定を変更しなければならなくなった多くの状況に遭遇しています。SAPアーキテクチャーには、ビジネス要求に迅速に対応し、ソリューションを迅速に実装し、フィードバックに基づいて改善し、そして繰り返し行うための十分な柔軟性が必要です。このブログ記事では、AWS上でのSAPアーキテクチャーにアジャイルをもたらす方法を示すために、例としてSAP Commerceを取り上げます。Minimum Lovable Product (MLP)で始めて、それからアーキテクチャーを迅速に変化させる方法を説明します。

Read More

Amazon CloudFront を活用したウェブサイトの可用性向上

Amazon CloudFront は、キャッシュ機能によるオリジンサーバー(CloudFront がコンテンツを取得する元のウェブサーバー)の負荷軽減とコンテンツ配信のパフォーマンス向上を実現できますが、可用性の向上もCloudFrontを活用することで得られる大きなメリットの1つです。CloudFront を利用する対象のウェブサイトのオリジンサーバーがAWS 上に存在する場合、オリジンサーバー側でもELB の活用や複数のアベイラビリティーゾーンの活用など可用性向上の為の様々なアプローチがありますが、CloudFront を利用することで更に高い可用性をウェブサイトにもたらすことが出来ます。 ウェブサイトの可用性を向上することは、ウェブサイトの応答速度の向上と同様にウェブサイトを運営する上で非常に重要な要素です。ウェブサイトの停止は、E コマースサイトでは売り上げに直接影響を及ぼしますし、コーポレートサイトや製品を扱うウェブサイトではブランドイメージや製品そのもののイメージ低下につながりかねません。 ウェブサイトの可用性に影響を及ぼす原因は様々なものがあります。例えば予期せぬハードウェア故障やネットワークの障害が原因となり、ウェブサイトが停止するリスクがあります。全てのコンポーネントを完全に冗長化することでリスクを軽減することが出来ますが、一般的なオンプレミス環境では冗長化の箇所が増える度にコストが大幅に増加する可能性があります。またウェブサイトオーナーは様々なキャンペーンなどの施策により、ウェブサイトのアクセス数の向上を目指しますが、予測を上回るアクセス増により、ウェブサーバーやネットワークが高負荷状態となりウェブサイトが停止するリスクがあります。 さらに外部からのDDoS 攻撃が原因となり、ウェブサイトの可用性に影響を及ぼすリスクがあります。攻撃者は複数のリソース (マルウェアに感染したコンピュータ、ルーター、IoT デバイスなどのエンドポイントで構成される分散グループ) を利用して、ターゲットのウェブサイトへの攻撃を実行します。攻撃者は侵害されたホストで構成されたネットワーク等を利用することにより、大量のパケットやリクエストを生成してターゲットのウェブサイトに過剰な負荷をかけます。たとえ正規のユーザーを想定したサイジングがきちんと出来ていても、悪意のあるトラフィックによる影響で、サーバーやネットワークのキャパシティが埋め尽くされ、ウェブサイトが停止してしまうリスクがあります。 今回はこのような予期せぬ障害やDDoS 攻撃による影響を回避し、ウェブサイトの可用性向上に役立つCloudFront の機能をまとめてご紹介致します。

Read More

[AWS Black Belt Online Seminar] サーバーレス イベント駆動アーキテクチャ 資料及び QA 公開

先日 (2020/06/10) 開催しました AWS Black Belt Online Seminar「サーバーレス イベント駆動アーキテクチャ」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200610 AWS Black Belt Online Seminar サーバーレスイベント駆動アーキテクチャ from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. オーダーサービスの例をとると、非同期になったことにより在庫が結果としてなかったなどの応答はどうやってクライアントに通知するべきでしょうか? A. このような場合に備えて補償トランザクションを定義します。具体的には注文を受け付けた時点では即座に注文を受け付けた状態としてクライアント側に応答しますが、在庫確認処理で在庫が無かった場合、後から在庫が無かったので注文がキャンセル(または入荷するまで処理をペンディング)される旨をメールで伝えるなどの処理を行うことになります。補償トランザクションはビジネスと密接に関わるため、関連するステークホルダーと協議して決めることになるでしょう。 Q. 福井さんの Black Belt でサーバーレスパターンの解説をしてほしいです。 A. リクエストありがとうございます。前向きに検討させて頂きます。 Q. SQS とSNS はどう使い分けるのでしょうか?過去事例では SQS + SNS を組み合わせるケースが多いように思いますが、組わせるメリットは何でしょうか? A. SNS はパブリッシュ(発行) / サブスクライブ( 購買)パターンを実現するサービスで、このパターンのメリットは発行者が購買者に対する知識を持つ必要がなく、発行者の実装に影響を与えることなく特定のトピックに関心がある購買者を自由に追加できる点にあります。さらに SNS には AWS Lambda、Amazon SQS、HTTP/S、Email、SMS […]

Read More
Lambda Thumb

新機能 – Lambda関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda

本投稿は AWS の Chief Evangelist (EMEA)であるDanilo Pocciaによる寄稿です。 AWS Lambda関数がAmazon Elastic File System(EFS)をマウントできるようになったことを非常に嬉しく思います。EFSは、高可用性と耐久性のために複数のアベイラビリティーゾーン(AZ)にまたがってデータを格納するスケーラブルでエラスティックなNFSファイルシステムです。このように、使い慣れたファイルシステムインターフェイスを使用して、関数単体、および複数のLambda関数のすべての同時実行環境にわたってデータを保存および共有できます。 EFSは、強力な整合性やファイルロックなどの完全なファイルシステムアクセスセマンティクスをサポートしています。 Lambda関数を使用してEFSファイルシステムを接続するには、EFSアクセスポイントを使用します。これは、ファイルシステムへのアクセス時に使用するオペレーティングシステムのユーザーとグループを含むEFSファイルシステムへのアプリケーション固有のエントリポイント、ファイルシステムのアクセス許可、およびファイルシステム内の特定のパスへのアクセスを制限できます。これにより、ファイルシステム構成をアプリケーションコードから切り離しておくことができます。 同一のアクセスポイント、または異なるアクセスポイントを使用して、複数の関数から同じEFSファイルシステムにアクセスできます。たとえば、異なるEFSアクセスポイントを使用して、各Lambda関数はファイルシステムの異なるパスにアクセスしたり、異なるファイルシステムのアクセス許可を使用したりできます。 同じEFSをAmazon Elastic Compute Cloud(EC2)インスタンス、Amazon ECSとAWS Fargateを使用するコンテナ化されたアプリケーションや、オンプレミスサーバーと共有できます。このアプローチに従って、異なるコンピューティングアーキテクチャ(関数、コンテナ、仮想サーバー)を使用して同じファイルを処理できます。たとえば、イベントに反応するLambda関数は、コンテナで実行されているアプリケーションによって読み取られる構成ファイルを更新できます。または、Lambda関数を使用して、EC2で実行されているWebアプリケーションによってアップロードされたファイルを処理できます。 このようにすると、いくつかのユースケースではLambda関数によって実装がより容易になります。例えば: /tmpで使用可能な容量(512MB)より大きいデータを処理またはロードする。 頻繁に変更されるファイルの最新バージョンをロードする。 モデルやその他の依存関係をロードするためにストレージ容量を必要とするデータサイエンスパッケージを使用する。 呼び出し間で関数の状態を保存する(一意のファイル名またはファイルシステムロックを使用)。 大量の参照データへのアクセスを必要とするアプリケーションの構築。 レガシーアプリケーションをサーバーレスアーキテクチャに移行する。 ファイルシステムアクセス用に設計されたデータ集約型ワークロードとの相互作用。 ファイルを部分的に更新する(同時アクセス用のファイルシステムロックを使用)。 アトミック操作でファイルシステム内のディレクトリとそのすべてのコンテンツを移動する。 EFSの作成 EFSをマウントするには、Lambda関数がEFSマウントターゲットに到達できるAmazon Virtual Private Cloud(VPC)に接続されている必要があります。ここでは、簡単にするために、各AWSリージョンで自動的に作成されるデフォルトのVPC を使用しています。 Lambda関数をVPCに接続する構成にすると、ネットワーク環境の変化に伴う変更が必要になることがある点に注意してください。 Lambda関数がAmazon Simple Storage Service(S3)またはAmazon DynamoDBを使用している場合は、それらのサービスのゲートウェイVPCエンドポイントを作成する必要があります。 Lambda関数がパブリックインターネットにアクセスする必要がある場合、たとえば外部APIを呼び出す場合は、NATゲートウェイを構成する必要があります。通常、デフォルトVPCの構成は変更しません。特定の要件がある場合は、AWS Cloud Development Kitを使用してプライベートおよびパブリックサブネットで新しいVPCを作成するか、これらのAWS CloudFormationのサンプルテンプレートのいずれかを使用します。このようにすることで、ネットワークをコードとして管理できます。 EFSコンソールで、[Create file system]を選択し、default のVPCとそのサブネットが選択されていることを確認します。すべてのサブネットで、同じセキュリティグループを使用してVPC内の他のリソースへのネットワークアクセスを提供するデフォルトのセキュリティグループを使用します。 次のステップでは、ファイルシステムにNameタグを付け、他のすべてのオプションをデフォルト値のままにします。 次に、[Add access […]

Read More

“共有型”AWS DirectConnectでも使えるAWS Transit Gateway

AWS Transit Gateway (TGW)は徹底的に進化することにより、クラウドネットワーキングを簡素化しました。本記事では、複数Amazon Virtual Private Cloud(VPC)とオンプレミスの接続パターンを紹介します。 AWSでは、オンプレミスのネットワークとの接続にはAWS Direct Connect(DX)を使います。DX接続は様々な形態がありますが、日本のお客様に多い“共有型”DX接続ではTGWを直接使うことができません。TGWを使うことができることが“専有型”DX接続の優位点の一つですが、本記事では”共有型”DX接続でTGWを使った接続実現する方法を含めて、いくつかの接続パターンを解説します。 TGWのメリット TGWを使用すれば、一貫した信頼性の高いネットワークパフォーマンス を実現しながら、複数のVPCおよびDXを使ってオンプレミスネットワークを相互接続するのはお手の物です。TGWは各VPC、VPN、DXの間のすべてのトラッフィクを一箇所で制御することができます。 専有型が利用できる場合にはTGWとDXをつなぐと、AWSを経由してインターネット接続することもできます。 上の例では、TGWがAWS Direct Connect Gateway(DXGW)にアタッチされています。 DXの複数VPCでの利用は典型的なユースケースです。一方で、DXは1Gbps以上の接続につきTGWのためのトランジット仮想インターフェースは1つだけという制限があります。つまり、日本のお客様に多い、“共有型”DX接続ではTGWを直接使うことができません。 ここでは、複数VPCとオンプレミスの接続パターンを以下4つに整理してみます。1つ目だけが、“専有型または1Gbps以上のホスト型接続”のみ実現可能です。 TGWにDXをつける DX用のVPCにNetwork Load Balancer(NLB)を配置。VPC間はTGW DX用のVPCにNLBを配置。VPC間はAWS PrivateLink(Private Link) DXGWにVPCをつける 1. TGWにDXをつける この場合、すべてのトラフィックはTGWで管理できます。AWSを経由したインターネット接続もProxyなしで実現できます。また、全トラフィックを”監査用アプライアンス”に通すことで全トラフィックの記録 / 制限 / 監査も可能ですので、セキュリティ面でも有利です。 2. DX用のVPCにNLBを配置。VPC間はTGW DXにつながるVPCとして“DX用VPC”1つが現れました。このとき、DXからみれば1つの”DX用VPC”がつながるだけですので、”共有型”でも問題ありません。VPC間の通信はTGWで設定制御ができます。 オンプレミス↔VPC間で通信をしなければならない特定のサーバのフロントにはDX用VPCにNLBを設置することで通信できるようにします。サーバの数だけNLBを設定するため、サーバ数が増えるとNLBの時間あたり費用がかさむことに注意してください。 3. DX用のVPCにNLBを配置。VPC間はPrivateLink このパターンでは、PrivateLinkが重要です。マイクロサービスなど、VPCを自由にいくつも使っている場合には、IPアドレスブロックが重複することはよくあることです。2つ目のパターンでは、TGWをつかってVPC間の通信を制御していました。TGWではアドレス重複の答えにはなりません。PrivateLinkはその解決策です。 VPC間およびオンプレミスとの特定の通信はPrivateLinkで設定します。VPCからオンプレミス上のサーバにアクセスするためにも使うことができます。 4. DXGWにVPCをつけたとき VPCとオンプレミスの間の通信はあるけれども、VPC同士の通信が無いのであれば、TGWは実は必要なかったのかもしれません。なお、一つのDXGWに接続できるVPCは10までですので、スケーラビリティにもやや難があるかもしれません。VPCの数が10以上になった場合、2つめの共有型Private VIFを利用する事により、多くのVPCと接続することができます。ただし、共有型VIFを増やし続けると、”1.”でご紹介した専有型接続の方が結果的に安価となる分岐点に到達します。詳細な見積もりが必要な場合は、利用するパートナー様にご確認ください。 比較 比較の一覧を追加しておきます。料金試算は、東京リージョンで、3つのサービス用VPCと1つのオンプレミスのネットワークを接続し、サービスするVPCひとつあたり月間10TB通信があり、DXのIn/Outの比率が1:1の場合です。(詳細は最後に) 案1: TGWにDXをつけたとき 案2: DX用のVPCにNLBを配置。VPC間はTGW 案3: DX用のVPCにNLBを配置。VPC間はPrivateLink […]

Read More