Amazon Web Services ブログ

多くの大企業は、タイムリーな情報を得るために、データ処理をバッチ処理からリアルタイム処理に移行しています。そうすることの課題は、リアルタイムのデータ処理アーキテクチャが着信データストリームに追いつけなければならないということです。これには、強固な耐障害性と伸縮性が必要です。 このブログ記事では、リアルタイムのデータ処理アーキテクチャと、Amazon RDS for SQL Server データベースへの変更をキャプチャして Amazon Kinesis Data Streams に送信する方法について解説します。Amazon S3 および AWS Lambda をデータの初期ロードに使用する方法と、AWS Database Migration Service を進行中のレプリケーションに使用する方法を示します。 AWS では、Amazon Kinesis Data Streams、AWS Database Migration Services (DMS)、AWS Lambda などのデータ処理を適正に行うためのサービスを数多く提供しています。DMS は、既存のデータを移行し、進行中の変更データをソースシステムからターゲットシステムにレプリケートするのに役立ちます。 前提条件および仮定 このソリューションを自分で使用するには、AWS のサービスへのアクセスを提供する AWS アカウントが必要です。 サービスは us-east-1 リージョンで作成する必要があり、ネットワーキングの考慮事項を簡素化するために us-east-1 リージョンの同じ VPC で設定する必要があります。 Lambda 関数のコンパイル済み Java コードは、この Amazon Repository にある ZIP ファイルに含まれています。S3 バケットを作成し、ZIP […]

  Formula One Group（Formula 1、以下F1）がAWSと提携し、クラウド化プロジェクトを開始しました。 F1は、21か国で開催する国際自動車連盟 (FIA) 主催のF1世界選手権 (FIA Formula One World Championship) の推進を担っています。 F1はITインフラストラクチャの大部分をオンプレミスのデータセンターからAWSクラウドへ移行予定です。フルマネージドな機械学習サービスAmazon SageMaker、イベント駆動型サーバーレスのコンピューティングサービスAWS LambdaやAWS分析サービスなど、さまざまなAWSサービスを通じてレース戦略とデータ追跡システムを強化し、世界で5億人を超えるファンとレーシングチームに、より確実な統計と予測情報を提供します。 F1の放送システムに関しても、複数の施設に及ぶ膨大なコンテンツデータをAWSのクラウドストレージで管理し、AWS Elemental Media Servicesで映像処理を行うというクラウドによるワークフローへ移行しました。複数の国でレースを行うため、現地にIT運用センターを設営する必要がありますが、クラウドを利用することで現地に運び込む機材が少なくなるため、クラウドが提供する効率性に加えて実用性な面でも利点を得ることができます。 F1は、非常にデータドリブンな自動車レースです。各レースでは、各競技車両が実装する120個のセンサーが3 GBのデータを生成し、毎秒1,500データポイントが生成されます。 F1のデータ科学者は、過去65年間で蓄積されたレースデータを使って深度学習モデルをトレーニングします。例えば、適切なピットストップウインドウ（適正なピットのタイミング）の特定や、タイヤ交換のピットストップ作戦といった、レース中の予測を行うことが可能です。リアルタイムでデータ分析をして、ドライバーが限界点までパフォーマンスを出しているかどうかといった洞察を、視聴しているファンに提供します。Amazon Kinesisを使って、機械学習、分析に用いる動画をリアルタイムにAWSのワークフローに取り込み、旋回中の各競技車両の主要なパフォーマンスデータを高速処理し、 Amazon SageMaker を活用した機械学習の結果により、ドライバーのパフォーマンスを正確に把握することができます。 F1のイノベーションとデジタル技術のディレクター、ピート・サマラ氏（Pete Samara）は次のように述べています。「AWSは我々のニーズに対して、他のクラウド事業者に勝るスピード、スケーラビリティ、信頼性、グローバル展開、パートナーエコシステム、そして幅広いサービスを提供してくれます。Amazon SageMakerなどの機械学習サービスを活用することにより、強力な洞察と予測をリアルタイムでファンに提供することができます。 また、AWSのスケーラブルで高性能コンピューティングワークロードを、Formula 1 Motorsports部門が活用できていることも素晴らしいです。これにより、新車のデザインルールの開発時に、エアロダイナミクス（空力性能）チームが実行できるシミュレーションの数と品質が大幅に向上します。」 原文はFormula One Group Case Study https://aws.amazon.com/jp/solutions/case-studies/formula-one/ AWSでの機械学習について https://aws.amazon.com/jp/machine-learning/ AWS ビデオソリューションについて https://aws.amazon.com/jp/digital-media/aws-managed-video-services/   AWS Elemental Marketing 山下  

この度、AWS GDPR (一般データ保護規則) に準拠したデータ処理補遺条項 (DPA) (.pdf) がオンラインサービス条件に組み込まれたことをご報告します。これにより、AWS のすべてのお客様が、グローバルに AWS GDPR DPA を利用できるようになりました。これは、2018 年 5 月 25 日以降、AWS のサービスを使用して一般データ保護規則に従って個人データを処理する場合に自動的に適用されます。AWS GDPR DPA には、欧州連合 (EU) のデータ保護機関によって承認され、29 条作業部会として知られる EU モデル条項も含まれています。このため、EU 加盟国及び欧州経済領域 (EEA) からそれ以外の国に個人データを転送する場合に、AWS の個人データが EEA で保護されるレベルと変わらない高いレベルで保護されるため、AWS のお客様は安心してデータを転送できます。 この発表は当社、お客様、APN（Amazon Partner Network）のパートナー各社にとって重要な GDPR コンプライアンスの構成要素となっています。クラウドサービスを使用して個人データを処理するすべてのお客様は、GDPR に準拠する場合、クラウドサービスのプロバイダーとの間にデータ処理契約を結ぶ必要があります。 2017 年 4 月の早い時期に、AWS は GDPR に対応した DPA をお客様が利用できることを発表しています。このように、2018 年 5 月 25 日の施行日より 1 年以上前に、当社はお客様への […]

この記事を書いている時点で、re:Invent 2018 開催まであと 138 日になりました。イベントチームの同僚たちは、全てのお客様がラスベガスで最高の経験ができるよう、総力を尽くしています。同僚とのミーティング後、この投稿を書くことにしたのは、お客様が会場にあるものをもっと理解し、何を期待できるかが分かり、お客様の方で計画と準備を進めることができるのでは、と思ったからです。 規模を考える このイベントの規模に関する課題について、考えることから始めました。2017 年のイベントには、約 43,000 人 (AWS のお客様、パートナー、報道関係者、業界アナリスト、AWS 従業員を含めて) が参加しました。クラウドアーキテクチャで使われるスケーリングの原則やベストプラクティスを数多く、このような大規模で複雑なイベントで重要となる物理的、ロジスティック的、そしてコミュニケーション上で生じる課題に対して適用しています。 場所の移動をもっと楽にしたいと同時に、そうする必要性自体を減らそうと考えています。私たちチームが現在行っていることは、次のようなものです。 キャンパスシャトル – 2017 年には、何百ものバスが数ある re:Invent の会場間を往復しました。その結果、運行系統に大幅な遅延が発生して、満足いくものではありませんでした。2018 年は、車両の数を増やし、直通だったバスを各停車場を巡る各停のものにし、さらにそれぞれの会場にはピックアップおよびドロップオフポイントを作りました。これで、行きたい場所へひとっ飛びです。 ライドシェアリング – Lyft と Uber (両社とも AWS をご利用くださっています) の協力の下、他にも交通手段をご用意しています (現在準備中ですが、アプリをダウンロードできます)。ラスベガスモノレールとタクシー会社にも協力いただいて、さらにはテレポーテーションサービスも現在準備していますが、開催に間に合うかどうかは未定です。 セッションアクセス – 複数の re:Invent 会場にまたがるしっかりとした予備スペースシステムも設置中で、人気の高いセッションを複数の会場で繰り返し行うことが可能となっています。 モバイルアプリの改善 – re:Invent のモバイルアプリはさらに使い勝手がよくなり、位置認識も行えるようになりました。空席のあるセッションを見つけたり、近くで何が行われているか、さらにはシャトルや他の交通手段を知らせてくれます。 みんなのためのもの re:Invent を参加者の皆様全員を暖かく歓迎する場所にし、斬新かつ開放的なビジネスやソーシャルのためのイベントにしたいと考えています。会場でのプランを少しお見せしましょう。 4 キロと 8 キロのチャリティファンラン – ファンランで一日を始めましょう。このイベントは Girls Who Code をサポートしています。 We […]

Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアのリーダーです。Autodesk は物を作る人のためのソフトウェアを作成しています。高性能の車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万人もの Autodesk ユーザーがソフトウェアで行っていることを体験したことがあると思われます。 Autodesk は Amazon RDS で稼働するマネージド MySQL データベースと Amazon EC2 でホストされるセルフマネージド MySQL データベースの両方からAmazon Auroraに移行しました。このブログ記事は、その経験をまとめ、次の点について取り上げます。 Autodesk の Amazon Aurora への移行決定に影響を与えた要因 移行上の特定の利点 移行と最適化に関して学んだベストプラクティスと教訓 まず、クラウドで生まれた Autodesk Access Control Management (ACM) アプリケーションの移行パスを確認します。始めに Amazon RDS for MySQL を選択し、スケーラビリティ、可用性、およびパフォーマンスを向上させるために Aurora に移行しました。ACM が移行を問題なく完了させたことで、Autodesk の他のいくつかのアプリケーションが Aurora に移行する意欲が高まりました。EC2 でホストされているセルフマネージド MySQL データベースを Amazon Aurora に移行する主要な例として、BIM 360 Field Classic について説明します。 […]

みなさん、こんにちは。 アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 AWS Summit Tokyo 2018 の基調講演にてアナウンスいたしました、Amazon Elastic File System (EFS)が東京リージョンで今日一般提供が開始されました。 Amazon EFSは複数のEC2からマウント可能なファイルストレージサービスです。従来ご利用いただいていたブロックストレージであるAmazon Elastic Block Store (EBS)との使い分けの考慮が大事なサービスとなりますので、その特徴とご利用における検討事項を纏めます。 Amazon EFS の特徴 Amazon EFSはシンプルで、スケーラブル、伸縮自在なファイルストレージを、AWS クラウドサービスとオンプレミスの両方でご利用いただくことが可能です。 シンプル – ファイルシステムを迅速かつ容易に作成および構成できるシンプルなウェブサービスインターフェイスを備え、ファイルストレージインフラストラクチャを管理するため、複雑なデプロイ、パッチ適用、複雑なファイルシステムデプロイメントを維持する必要はありません。また課金体系もシンプルであり、保存されているデータ容量にたいしてのみ課金されます。東京リージョンでの価格は0.36USD / GBとなります。 スケーラブル – ファイルシステムの拡大に合わせて、スループットおよび IOPS が自動でスケールされます。こちらにパフォーマンスについてはまとまっています。 伸縮自在 – ファイルの追加や削除に合わせてファイルシステムのストレージ容量を直ちに自動で拡張または縮小でき、これによりスループット及びIOPSが変動します。 高可用性および高耐久性 – ファイルシステムの各オブジェクト (ディレクトリ、ファイル、リンクなど) は、複数のアベイラビリティーゾーンに冗長的に保存されるため、高いレベルの可用性と耐久性を確保できます。 オンプレミス環境からの利用 – AWS Direct Connect で Amazon VPC に接続し、オンプレミスのデータセンターサーバーにファイルシステムをマウントすることが可能です ご利用上の留意点 EFS はNFS v4 プロトコルをサポートしています。NFS […]

AWS re:Invent に参加した Discover Financial Services (DFS) のチームメンバーが、Robocar Rally はインパクトがきわめて強いイベントだったと語りました。Discover のコアチームのメンバー 6 名はこのハッカソンに参加し、機械学習 (ML) および AWS に関する深層学習を使用したハンズオン体験をしました。彼らにとってその楽しい時間は、永く記憶に残るものとなりました!Discover の Cloud Center of Excellence (CCoE) はのちに、ある 1 つのアイデアを提案しました。それは、「Discover 本社のオンサイトで同じイベントを再現してみよう」というものです。Discover CCoE にはそのリーダーシップおよびデータサイエンスチームをもって機械学習実験の現状にインパクトを与えるために、AWS AI/ML サービスに対する認識を高めようという目標がありました。そのイベントが実現するのに、2 か月半かかっていません。 チーム編成 Discover はイベント開催中にチームあたり 6 名からなる 6 チームを編成し、ハッカソンに参加して、1 対 1 で直接競わせました。Discover は多数の事業領域にわたる多様な縮図を体現しています。これが開発者からセキュリティ専門家にいたる混合環境を構築しており、そこには機械学習の関係者も含まれます。チーム規模およびチーム数は、カスタマーの関心と過去の Robocar Rally のイベントから継承されてきた知見をすり合わせた結果としてそうなりました。 Robocar の役割 AWS はこのイベント運営および各チームメンバーに対する戦略的な役割分担を目指して、規範的なアプローチを使用しました。 ドライバー: モデルのトレーニング中はクリーンデータの収集を確保しながら、車両を管理し、イベント開催中は Robocar を管理します。 Robo […]

Lambda@Edge をより活用いただくために Lambda＠Edge ベストプラクティスシリーズと題したブログを連載します。この中ではいくつかのユースケースを用いて Lambda@Edge をどのように利用すればよいか、CI/CD パイプラインにどのように組み込むべきか、ビジネスニーズに応える形で組み込まれていることを担保するためにはどのように考えればよいか等について取り上げます。 記念すべき初回は Lambda@Edge のデザインベストプラクティスについて取り上げます。いくつか一般的なユースケースをもとに関数をどのタイミングで実行するのが良いのか、それはどのような観点で選択されるべきかということについてパフォーマンス及びコスト最適化の観点から推奨構成について説明していきたいと思います。

MySQL と互換性がある Amazon Aurora はデータベースワークロード統合を検討中のお客様から好評をいただいています。Aurora MySQL は、ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。また Aurora MySQL は、標準の MySQL Community Edition に比べ最大 5 倍のスループットを実現します。 今回のブログ記事では、大規模な統合データベースワークロードのために行う Amazon Aurora の最適化に役立つガイダンスをいくつかお伝えします。また、「統合の費用はどれくらいかかりますか?」や「データセットはどのくらいの大きさにできますか?」など、よくある質問にお答えします。 上記の質問はシンプルですが、必ずしも回答がシンプルになるわけではありません。回答は、お使いのデータセットやワークロードのパターンによって大きく異なります。 データベース統合の定義 統合のユースケースに関しては、以下の要素に的を絞り、それからコンテキストに応じた Aurora MySQL の操作方法について詳細を説明します。 テーブルのサイズ。統合により、一般的にテーブルは大きくなります。アドテック、IoT、消費者向けアプリケーション分野の場合、通常は大きな同種アプリケーションのデータベースをそれぞれにデータのサブセットが含まれる大量のシャードに分割します。Aurora ではシャーディングを完全になくすことはできないかもしれませんが、より少数のシャードに統合して操作上のオーバーヘッドを減らすことができます。 テーブルの数。テーブル数の増加も、統合の結果見られることです。この結果は、各テナントが通常、独自のデータベースまたはテーブルセットを有する場合にテナントの分離が必要な SaaS アプリケーションで一般的なものです。このタイプの複数のテナントは数が少なくより大きな Aurora クラスターにまとめられ、テナントあたりの操作コストを削減します。 データベースの使用率。さらに多数の同時接続を行うなど、統合データベースワークロードの使用率が多くのメトリクスで増加します。 実際には、同じプロジェクト内の複数の要素で使用率が増加することになります。以下のガイドラインは、各要素でワークロードを最適化するのに役立つはずです。 「大きい」とは具体的にどのくらいのサイズですか? Amazon Aurora には最大容量に制限があります。私たちの最も重要な成果は、Aurora クラスターで 64 TB という最大の保存容量です。最大容量により、Aurora クラスターに物理的に保存できるデータ量の上限が決められます。また、個々のテーブルの大きさについて上限が決められます。 加えて、MySQL と互換性があるデータベースエンジンとして、Aurora MySQL は MySQL と InnoDB ストレージエンジンから多くの特徴を受け継いでいます。これらの特徴には効果的な統合に影響を与えるものがあります。 大きなテーブルサイズを最適化する方法 Amazon Aurora […]

この記事では、Amazon Relational Database Service (Amazon RDS) for PostgreSQL 中央データベースを、Amazon Kinesis Data Streams にその変更をストリーミングすることで、他のシステムと統合する方法について説明します。以前の記事、「Amazon Kinesis を使用したデータベースの変更をストリーミングする」では、変更を Kinesis へストリーミングすることによって、MySQL データベース用の中央 RDS を他のシステムに統合する方法についてお話ししました。この記事では、さらに進んで、AWS Lambda 関数を使用して Amazon RDS for PostgreSQL の変更をキャプチャし、その変更を Kinesis Data Streams にストリーミングする方法を説明します。 次の図は、分散システムにおける一般的なアーキテクチャ設計を表しています。これには、信頼できる唯一の情報源と呼ばれる中央ストレージと、この中央ストレージを使用するいくつかの派生「サテライト」システムが含まれます。 この設計アーキテクチャーを用いて、データの整合性を維持するためにこのシステムのトランザクション機能を活用しながら、リレーショナルデータベースを中央データストアとして使用することができます。このコンテクストにおいての派生システムとは、全文検索システムであり、この信頼できる唯一の情報源の変更を観察し、それらの変更を変換かつフィルタリングし、最終的にその内部インデックスを更新するものです。もう 1 つの例は、OLAP クエリにより適したカラムナストレージです。一般に、中央リレーショナルシステムの個々の行が変更された時にアクションを実行する必要があるシステムはどれも、派生データストアにするのに適しているとい言えます。 この種のアーキテクチャの単純な実装では、変更された行を検索するために定期的にクエリを発行する派生システムがあります。これは基本的に SELECT ベースのクエリ (バッチ処理システムとも呼ばれます) で中央データベースをポーリングします。一方で、このアーキテクチャにより適した実装は、非同期の更新ストリームを使用するアーキテクチャです。 データベースには通常、行のすべての変更が格納されるトランザクションログがあります。ですので、この変更のストリームが外部のオブザーバシステムに公開されている場合、このシステムはこれらのストリームに接続し、行の変更を処理およびフィルタリングできる可能性があります。 この記事では、PostgreSQL を中央データベースとして、また Kinesis Data Stream をメッセージバスとして使用して、この基本的な実装を紹介します。 通常、PostgreSQL Write-Ahead Logging (WAL) ファイルは、マスター上のすべての変更を読み込んだ後、ローカルに適用するリードレプリカに公開されます。リードレプリカからデータを読み取る代わりに、wal2json 出力プラグインを用いた論理デコードを使用して、WAL の内容を直接デコードします。プラグインはこの GitHub […]