Amazon Web Services ブログ

Amazon DynamoDB が、7 歳の誕生日!

7 年前の今日、AWS の CTO であった Werner Vogels が Amazon DynamoDB のリリースを発表しました。そこで、2018 年と 2017 年の「最新情報」の記事を振り返って、DynamoDB の最近の成長を示すのもおもしろいだろうと考えました。こうした記事は、トランザクション、オンデマンドキャパシティモード、ポイントインタイムリカバリ、グローバルテーブル、バックアップとリストア、Auto Scaling など、さまざまな機能リリースをすべて説明しています。

Read More

Amazon RDS for Oracle における UTL_FILE 問題の解決

 データベースと各種アプリケーションサーバー間でファイルを転送するための一般的な手法として、Oracle の機能である UTL_FILE があります。UTL_FILEを使うと、クライアントサーバーが POSIX 対応のディレクトリにファイルをコピーし、その後そこからファイルを読み取ることを可能にします。さらに、データベースが PL/SQL ルーチンを使用して、これらの同じファイルに対する読み取りと書き込みを行うことも可能にします。 しかし Amazon RDS 上のOracle Databaseへの移動時には、UTL_FILEを用いたファイル転送において問題が生じます。データベースはサーバ上のファイルの読み取りと書き込みを実行できるのですが、これらのディレクトリは外部システムに公開されていないため、外部システムはそれらにアクセスできません。この問題は、多くの組織にとって Amazon RDS for Oracle を導入する妨げとなっています。 このブログ記事では、この問題を解決するプロセスについて順を追って説明していきます。このプロセスは、Oracle PL/SQL ルーチンを使用して Amazon S3 バケットに Oracle RDS インスタンスを統合することによって問題を解決します。こうすることで、現在 UTL_FILE によって提供されている機能性に似た外部ファイル転送メカニズムが提供されます。 このブログ記事では、Amazon RDS for Oracle インスタンスの変更プロセスのみを取り上げます。追加の参照情報は、以下のドキュメントトピックで見つけることができます。これらは、RDS for Oracle インスタンスを作成して、そのインスタンスにアクセスするためのプロセスを説明しています。 Amazon RDS のセットアップ Amazon RDS の使用開始 Oracle DB インスタンスを作成して Oracle DB インスタンス上のデータベースに接続する また、以下のドキュメントトピックにも追加の参照情報があります。これらには、このプロセスをテストするための S3 バケットの作成プロセスが説明されています。 Amazon Simple […]

Read More

弊社のデータレイク物語:Woot.comはどのようにしてAWS上でサーバーレスデータレイクを構築したか

この投稿では、当社が受け継いできた関係データベース上に構築されたデータウェアハウスの代替としての、cloud-nativeデータウェアハウスの設計についてお話します。 設計過程のはじめで、最も簡単に見える単純なソリューションは、関係データベースから他のものへのリフト&シフトマイグレーションです。しかし、当社は一歩戻り、まずはデータウェアハウスで何が本当に必要とされているかに焦点を当てることに決めました。当社はどのようにして、正しいツールを適した業務に使用することにより、従来のオラクルデータベースをより小さなマイクロサービスに分離できるかに着目し始めました。当社の方法はAWSツールを使用するだけではありませんでした。さらに、それはcloud-native技術を使用して当社を最終状態に持っていくためにマインドシフトすることでした。 このマイグレーションには既存データもマイグレートさせながら新規のデータを流入させるために、新規の抽出、変換、ロード(ETL)パイプラインが必要でした。このマイグレーションのため、AWS Glueに統合されることにより、当社は多くのサーバーを除去し、完全にサーバーレスのデータウェアハウスに移行することができました。 このブログ投稿で、当社は以下をご覧に入れます: 当社がデータウェアハウスのためにサーバーレスデータレイクを選択した理由。 Woot’sシステムのアーキテクチャー図。 マイグレーションプロジェクトの概要。 当社のマイグレーションの結果。 アーキテクチャーおよび設計の関係 こちらは当社が考慮した設計重点の一部です: 顧客体験。当社は常にお客様が必要とすることから始め、そこから戻るように業務を行いました。当社のデータウェアハウスは様々なレベルの技術専門性を持った人々による事業を渡って使用されます。 当社は異なるタイプのユーザーが運用の中に識見を持つ能力に焦点を当て、全体的な顧客体験を向上させるために、より良いフィードバックメカニズムを提供します。 最小限のインフラストラクチャーメンテナンス。「Wootデータウェアハウスチーム」は本当にたった一人の人です-Chaya! このため、当社がcloud-native技術を使用することができるAWSサービスに集中することは当社にとって重要です。これらは需要が変化し、技術が進化するにつれ、未分化性のインフラストラクチャーの管理といった困難な仕事を取り除きます。 データソースの変化に対する応答性。当社のデータウェアハウスは内部サービスの範囲からデータを取得します。弊社の既存のウェアハウスでは、これらのサービスへのいずれの更新でETL業務および諸表で手動による更新が必要でした。これらのデータソースのための応答時間は当社の主要関係者にとって重大なことです。このために当社は高性能アーキテクチャーの選択に向けたデータ主動のアプローチが必要でした。 生産システムからの分離。当社の生産システムへのアクセスは固く結びついています。複数のユーザーを許容するため、当社はそれを生産システムから分離し、複数のVPCsでのリソースをナビゲートすることの複雑さを最小化する必要がありました。 これらの要件に基づき、当社は運営面およびアーキテクチャーの面の両方で、データウェアハウスを変更することを決定しました。運営の観点から、当社はデータ摂取の目的で新規の共有応答モデルを設計しました。アーキテクチャーの面で、当社は従来の関係データベースに代わってサーバーレスモデルを選択しました。これら2つの決定は、当社がマイグレーションで行った、すべての設計および実装の決定を動かすこととなりました。 当社が共有応答性モデルに移行するにあたって、複数の重要な点が浮上しました。第一に、当社のデータ摂取の新しい方法はWootの技術組織にとっては主要な文化シフトでした。過去に、データ摂取は専らデータウェアハウスチームの担当で、サービスからデータを引っ張るためにカスタム化されたパイプラインが必要でした。当社は「押し、引かない」にシフトしました:サーバーがデータウェアハウスにデータを送信するべきである。 これが共有責任が行き着いたところでした。初めて、当社の開発チームがデータウェアハウスのサービスデータ全体の所有権を持ちました。しかし、当社は開発者にミニデータエンジニアになってほしくありませんでした。代わりに、当社はデータをプッシュするために、彼らに開発者の既存のスキルセットに適合する簡単な方法を示しました。データは当社のウェブサイトで使用される技術の範囲でアクセス可能である必要がありました。 これらの検討されたことは当社をサーバーレスデータウェアハウス向けの、以下のAWSサービスを選択することに導きました。 データ摂取用Amazon Kinesis Data Firehose データ保存用Amazon S3 データ処理用AWS Lambda および AWS Glue AWS データマイグレーションサービス (AWS DMS) および データマイグレーション用AWS Glue 統合およびメタデータ管理用AWS Glue クエリおよびデータ視覚化用 Amazon Athena および Amazon QuickSight 以下のデータグラムは当社がどのようにこれらのサービスを使用するかをハイレベルで示します。 トレードオフ これらの構成要素は共に当社のすべての要件を満たし、共有責任モデルを実行可能にしました。しかし、当社はリフト&シフトマイグレーションをもう一つの関係データベースと比較し、数回のトレードオフを行いました。 最大のトレードオフは先行投資の努力対進行中のメンテナンスでした。当社はすべてのデータパイプラインをもって効果的に白紙の状態から開始し、新しい技術を当社のすべてのウェブサイトサービスに導入しました。これには複数のチームを渡り協力的な努力が必要となりました。最小限の現行メンテナンスは核心要件でした。当社が使用するサーバーレスコンポーネントの管理されたインフラストラクチャーの優位点を利用するために、当社は快くこのトレードオフを行いました。 もう一つのトレードオフは非技術ユーザー対ビッグデータテクノロジーを利用することの有用性のバランスを取ることでした。顧客体験を核心要件にすることは、当社がこれらのトレードオフを検討するときに、意思決定を導くのを助けました。最終的には、他の関係データベースへの切り替えは、当社のお客様が同じ体験をするだけで、より良い体験をするわけではなかったのです。 Kinesis Data Firehose および […]

Read More

AWS がエッジデバイスの ML 展開を加速するオープンソースの Neo-AI プロジェクトをロンチング

 re:Invent 2018 で、Amazon SageMaker Neo が発表されました。機械学習モデルを一度トレーニングすると、クラウドおよびエッジ内ではどこでも実行できる新しい機械学習機能です。今日、私たちは Apache Software License の下でオープンソースの Neo-AI プロジェクトとしてコードを公開しています。このリリースでは、プロセッサベンダー、デバイスメーカー、および深層学習の開発者が、機械学習における新しい独自のイノベーションをさまざまなハードウェアプラットフォームにすばやく取り入れることができます。 通常、開発者は各プラットフォームのハードウェアおよびソフトウェア構成に合わせて、モデルを手動で調整する必要があるため、複数のハードウェアプラットフォームに対して機械学習モデルを最適化することは困難です。コンピューティング能力とストレージが制約される傾向があるエッジデバイスにとっては、特に困難です。これらの制約により、実行できるモデルのサイズと複雑さが制限されます。そのため、最高のパフォーマンスを得るために、開発者が手動でモデルを調整するのに数週間または数ヶ月かかります。調整プロセスには、最適化手法に関する稀な専門知識とハードウェアに関する深い知識が必要です。それでも、優れたツールをすぐに利用できないため、優れたパフォーマンスを得るには、通常、かなりの試行錯誤が必要となります。 ソフトウェアの違いにより、この作業はさらに複雑になります。デバイス上のソフトウェアがモデルと同じバージョンでない場合、モデルはデバイスと互換性がありません。これにより、開発者は自分のモデルのソフトウェア要件と完全に一致するデバイスのみに制限するようになります。 したがって、機械学習アプリケーションをすばやく構築、拡張、および維持することは非常に困難です。 Neo-AI は、TensorFlow、MXNet、PyTorch、ONNX、および XGBoost モデルを自動的に最適化して、最大元のモデルの 2 倍速で正確性を損なうことなく実行できます。これにより、複数プラットフォームへ展開する機械学習モデルの調整に必要な時間と労力を省きます。さらに、ソフトウェアの互換性の問題を排除するために、モデルを効率的な共通フォーマットに変換します。ターゲットプラットフォームでは、コンパクトなランタイムによって通常のフレームワークが消費するリソースのごく一部を使用します。最適化を簡素化にすることによって、Neo-AI は洗練されたモデルがリソースに制約のあるデバイス上で動作することを可能にします。また、そこで自律走行車、ホームセキュリティ、および異常検出などの分野におけるイノベーションを引き出します。Neo-AI は現在、Intel、NVIDIA、および ARM のプラットフォームをサポートしており、Xilinx、Cadence、および Qualcomm のサポートも近日中に開始する予定です。 Neo-AI は、主要な機械学習コンパイラであり、LLVM や Halide など従来のコンパイラテクノロジーに関する、数十年にわたる研究に基づいて構築されたランタイムです。Neo-AI コンパイラには、ワシントン大学で開始したオープンソース研究プロジェクトの TVM と Treelite に対する修正が含まれています。今日の Neo-AI プロジェクトを通じて AWS コードをオープンソースにリリースすることで、開発者はプロダクショングレードの Neo コンパイラとランタイムをイノベーションすることができます。Neo-AI プロジェクトは、AWS、ARM、Intel、Qualcomm、Xilinx、Cadence などを含め、複数の組織によって進められます。 Neo-AI プロジェクトと連携することで、モデルのパフォーマンス向上に最大の効果を発揮する時点で、プロセッサベンダーはカスタムコードをコンパイラにすばやく統合できます。このプロジェクトにより、デバイスメーカーは、デバイス特定のソフトウェアおよびハードウェアの構成に合わせて Neo-AI ランタイムをカスタマイズすることもできます。Neo-AI ランタイムは現在、ADLINK、Lenovo、Leopard Imaging、Panasonic などのデバイスに導入されています。Neo-AI プロジェクトは、さまざまなソースによるイノベーションを機械学習用の共通コンパイラおよびランタイムに吸収して、利用可能な最高のパフォーマンスをモデルに提供します。 Intel の […]

Read More

AWS Black Belt オンラインセミナーのご案内 (2019 年 2月)

こんにちは。マーケティングの鬼形です。2 月の AWS Black Belt オンラインセミナーについてご案内させて頂きます。 2月は、新サービスAmazon DocumentDBや2回に渡るAmazon SageMaker特集などを開催します!ぜひお役立てください。 視聴方法: オンラインセミナー登録ページよりお申し込みください 公共機関におけるAWSの利活用 2019 年 2 月 5 日 | 12:00 – 13:00 | IT 知識レベル:★★☆☆☆ | AWS 知識レベル:★★☆☆☆ 公共機関においてもAWSの利活用が加速しています。今回は、AWSの利用を推進する中でのセキュリティやコンプライアンス観点でのポイントをお伝えします。 対象者 ビジネスドライバの方 本セミナーで学習できること AWSと公共系コンプライアンス スピーカー 松本 照吾 Security Consultant, Pub Sec   Amazon SageMaker Basic Session 2019 年 2 月 6 日 | 18:00 – 19:00 | […]

Read More

[AWS Black Belt Online Seminar] Amazon Redshift Update 資料及び QA 公開

先日 (2018/1/22) 開催しました AWS Black Belt Online Seminar「Amazon Redshift Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190122 AWS Black Belt Online Seminar Amazon Redshift Update from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Redshiftアドバイザ実行中、Redhiftのパフォーマンスに影響を及ぼさないでしょうか? A. Redshiftアドバイザのための各種ログ収集は内部的にスケジューリングされて自動実行され、パフォーマンスに影響を及ぼさないように動作します Q. クエリエディタについて質問です。ds2.xlargeでも、将来的に使えるようになるのでしょうか? A. 将来的なことはご回答できませんが、お客様のRequestに答えられるよう活動してまいります​ 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております! AWS Black Belt Online Seminar 1月分申込先 ≫ AWS Black Belt Online Seminar 2月分申込先 ≫ 2019 年 1 […]

Read More

舞台裏のシークレット – AWS re:Invent 2018 の動力となった CenturyLink ネットワーク

長年のブログ読者なら、私が現代世界の大部分を可能にし、それらを動かしている舞台裏そして地下の活動に興味をそそられることをすでに把握しておられるかもしれません。例えば、私は昨年末、どのように AWS クラウドが re:Invent で地下に潜るかについて説明し、re:Invent の参加者と、遠方からキーノートとライブストリーミングをご覧になっていた皆さんに最高の接続性を提供するために使用された、通信およびネットワークインフラストラクチャに関する情報をお伝えしました。 Invent 2018 が過去のものとなり、来年の計画がすでに進められている今日、5 回に渡って re:Invent ネットワークサービスプロバイダーを務めた CenturyLink が、180 Gbps の帯域幅を提供するために AWS Direct Connect を使用する冗長性と回復性を備えたネットワークを設計して構築し、8 つの会場全体で接続された 81,000 個を超えるデバイスをサポートした方法について説明したいと思います。地上では、各会場における ShowNets のカスタムネットワークと WiFi デプロイメントを CenturyLink によって提供されたインフラストラクチャに接続するために、ShowNets と密接に連携しました。 2018 re:Invent のネットワーク 2018 年、このネットワークには、Sands Expo、Wynn Resort、Circus Circus、Mirage、Vdara、Bellagio、Aria、および MGM Grand の各施設を網羅した最新のマルチノードメトロファイバーリングによる、複数の AWS リージョンへの多様なルートが含まれていました。各会場、そして複数の AWS Direct Connect ロケーションに対する 10 Gbps の冗長接続が、優れた可用性を確保にするために使用されました。ネットワークは CenturyLink Cloud Connect Dynamic Connections […]

Read More

AWS Backup – バックアップの自動化と集中管理

AWS を使用すると、ファイルシステム、ブロックストレージボリューム、リレーショナルデータベース、NoSQL データベース、および貴重なデータを保存するその他のリソースを簡単かつ動的に作成できます。必要に応じてすぐに作成し、必要なだけストレージにアクセスできます。これにより、大規模なクラウド移行への扉を開くことができます。機密データをクラウドに移行する際に、ビジネス要件および法令遵守要件を引き続き満たしていることを確認する必要があります。また、間違いなくアプリケーションのエラーから保護されていることを確認する必要があります。 上記の多くのサービスに組み込まれている組み込みのスナップショット操作を使用して、独自のバックアップツールを作成することができます。ただし、企業全体のバックアップ戦略とそれを実装するツールを作成するには、まだ多くの作業が必要です。私たちは変化をもたらすために努めています。 新しい AWS バックアップ AWS Backup は、バックアップの自動化と集中管理を支援するように設計されています。中央コンソールを使用して、ポリシー主導のバックアッププランの作成、進行中のバックアップステータスのモニタリング、コンプライアンスの検証、バックアップの検索または復元をすべて行うことができます。既存の AWS スナップショット操作と新しい専用バックアップ操作の組み合わせ、そして古いバックアップを Amazon Glacier に階層化する機能を使用して、バックアップは EBS ボリューム、EFS ファイルシステム、RDS  データベース、DynamoDB テーブル、および Storage Gateway ボリュームを Amazon Simple Storage Service (S3) にバックアップします。バックアップには Storage Gateway ボリュームのサポートが含まれているため、作成したバックアップに既存のオンプレミスデータを含めることができます。 各バックアッププランには、1 つ以上のバックアップルールが含まれています。ルールは、バックアップスケジュール、頻度、およびバックアップウインドウを表します。バックアップするリソースは、タグを使用して明示的に、またはポリシー主導の方法で識別できます。ライフサイクルルールは、ストレージの階層化と古いバックアップの有効期限を制御します。バックアップは、回復ポイントを定義するコレクションに、一連のスナップショット、そしてスナップショットと共に移動するメタデータを集めます。毎日、毎週、毎月のバックアップ戦略を制御し、重要なデータが要件に従って確実にバックアップされていることを確認し、必要に応じてデータの復元機能を定義することができます。バックアップはボールトにグループ化され、それぞれが KMS キーで暗号化されます。 AWS バックアップの使用 数分で AWS Backup を始められます。AWS Backup コンソールを開き、[バックアッププランの作成] をクリックします。 最初からプランを立てるか、既存のプランから始めるか、または JSON を使用してプランを定義することができます。[新しいプランを立てる] を選択して、プランに名前をつけることから始めてみます。 今度はバックアッププランの最初のルールを作成します。これを MainBackup と呼ぶことにします。毎日実行し、(1 ヵ月後にコールドストレージに移行し、6 ヵ月後に期限切れにする)ライフサイクルを定義し、[デフォルト] ボールトを選択します。 […]

Read More

一元化された AWS バックアップサービス、AWS Backup の紹介

昨日サービスの提供が開始された AWS Backup は、完全マネージド型の AWS バックアップソリューションを提供するために Amazon DynamoDB、Amazon EBS、Amazon RDS、Amazon EFS、および AWS Storage Gateway と統合されています。AWS Backup は、クラウド内だけではなくオンプレミスの AWS のサービス全体におけるデータのバックアップと保持を一元化し、自動化します。AWS Backup コンソールの統合されたビューによって、バックアップの監視、バックアッププランの管理、および監査情報の提供を行うことができ、内部ポリシーと外部の規制監査に対するコンプライアンスを確実にするプロセスがシンプルになります。 地域ごとの可用性に関する情報については、AWS のリージョン表を参照してください。 詳細については、完全な AWS News Blog 記事をお読みください。   著者について Craig Liebendorfer は、アマゾン ウェブ サービスのシニアテクニカルエディターです。この写真は、アイスランドでバスを待っている Craig と Elizabeth です。    

Read More