Author: AWS Japan

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

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

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

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

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

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

本投稿は 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 […]

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のためのトランジット仮想インターフェースは１つだけという制限があります。つまり、日本のお客様に多い、“共有型”DX接続ではTGWを直接使うことができません。 ここでは、複数VPCとオンプレミスの接続パターンを以下４つに整理してみます。1つ目だけが、“専有型または1Gbps以上のホスト型接続”のみ実現可能です。 TGWにDXをつける DX用のVPCにNetwork Load Balancer(NLB)を配置。VPC間はTGW 通信方向に合わせてエンドポイントサービス（NLBとインターフェイスエンドポイントのペア）を配置 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. 通信方向に合わせてエンドポイントサービス（NLBとインターフェイスエンドポイントのペア）を配置 このパターンでは、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: 通信方向に合わせてエンドポイントサービス（NLBとインターフェイスエンドポイントのペア）を配置 案4: DXGWにVPCをつけたとき […]

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も週刊AWSをお届けします。 AWS Summit Onlineの開催が発表されました！ 期間は9月8日(火) ～ 9月30日(水)で、日本では初のフル・オンライン開催のAWS Summitになります。期間中はセッションをオンデマンドでいつでもどこでも見られる形になる予定です。また9月8日(火) 、9月15日(火) はライブセッションをチャット形式で行う予定で、これまで会場の”ASK the Expert”コーナー等でお受けしていたエンジニアへのご相談をオンラインチャットで受け付ける試みも行う予定です。 – AWS Summit Online Japan 2020 オンライン開催ということで日本のどこからでも参加できますので、ぜひこちらのURLから事前登録をしておいていただければと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。

温度や湿度、加速度などのセンサーを設備に取り付け、その値をクラウドに上げて可視化する、といったユースケースは、商業施設や工場など様々なユースケースで求められています。AWS IoTをはじめとする、AWSのサービスを使うことで、そういったユースケースをすばやく実現することが可能です。これはAWS IoTで管理されているデバイスに限った話ではありません。他のデバイス管理ソリューションをお使いの場合においても、クラウドアプリケーションやデータ分析の用途でAWSをシームレスに利用頂くことができます。 この記事では、Arm Pelion Device Management上で管理されているデバイスから、ログデータをAWS IoT にアップロードし、分析・可視化を行う方法について、具体的な構築手順をご紹介します。ここではWi-Fi環境がない設置場所を想定し、通信手段として3G回線を使用します。また施設内のアラートを管理者に伝えるといったシーンを想定し、記事の後半ではデバイスのボタンを押すと管理者にメールが届く仕組みも構築します。最後に、身近なデバイスでクラウド開発のPoCをクイックに進める手段として、Pelion Device Managementで管理されているRaspberry PiでAWS IoT Coreに接続する方法を紹介します。 概要 今回構築する仕組みは、上記のようなアーキテクチャになります。まず、Mbed OSが動作するマイコンが、Pelion Device Managementで管理されています。デバイスは、MQTTプロトコルによって時系列のセンサーデータを3G回線を経由してIoT Coreへアップロードします。IoT Coreのルールエンジンを使って、分析対象のデータのみをIoT Analyticsに送ります。IoT Analyticsでは、収集、処理、保存といった分析の前処理を行いデータセットを作成します。最後に作成したデータセットをQuickSightからアクセスすることでセンサーの時系列データをグラフ描画することが可能になります。 さらに、ここでは触れませんが、AWS IoT Analyticsを用いて作成したデータセットをAmazon SageMakerというAI・MLのサービスにわたすことで、機械学習による高度な予兆保全や、アノマリー検出なども可能になります。 AWS IoTの認証には、2020年5月に追加されたAWS IoT CoreのMulti-Account Registrationの機能を使用します。これによって、Pelion Device Managementで発行された証明書をIoT Coreに設定するだけで、デバイスは1つの証明書を使って接続することができます。 準備 こちらの記事 の4.2章までを実施し、SIMの設定、センサーおよびボタンの接続、Pelion Portal Account の設定を進めてください。以下は、事前に用意していただくハードウェアです。 使用するハードウェア Seeed Wio 3G GROVE – 温湿度・気圧センサ（BME280） GROVE – 青LEDボタン SIMカード Raspberry Pi 3 […]