Amazon Web Services ブログ

Tag: General

AWS Media Services – クラウドベースの映像処理、保存、収益化

初期のWebビデオがどんなものだったのか覚えていますか? スタンドアローンのプレーヤー、低速で不安定な接続、過負荷なサーバー、そして今まで存在していたバッファリングメッセージは、20年も前に標準策定されたものでした。 今日、技術の進歩と幅広い標準のおかげで、物事はずっと改善されています。 視聴者は現在様々な操作が可能で、様々な形、サイズのデバイスを使用して、ブロードキャスト、ストリーミング、またはOTTで送信されたライブおよび録画コンテンツを楽しむことができ、それらコンテンツへの即時アクセスが期待できます。 これらの期待に応えることは、コンテンツクリエイターとディストリビューターにとってのチャレンジです。 ワンサイズのすべての形式でビデオを生成する代わりに、メディアサーバーは、幅広いサイズ、フォーマット、およびビットレートに対応するビデオを制作する準備ができていなければなりません。計画的または計画外の需要の急増にも注意をしなければなりません。このような複雑さに直面しても、コンテンツ収益化モデルを保護するために、コンテンツ及び安定供給するインフラ準備が必要となります。 New AWS Media Services 2017年11月27日、上記課題の1つまたは複数に対応するよう設計された、様々な放送品質のメディアサービスを開始します。これらを一緒に使用して完全なエンドツーエンドのビデオソリューションを構築することも、ビルディングブロックスタイルで1つ以上のサービスを組み合わせて使用することもできます。皆様はインフラストラクチャーのセットアップに使う時間を短縮し、より革新的なコンテンツの作成、配信、収益化に集中することが可能です。サービスはすべて伸縮可能であり、処理能力、接続、ストレージを強化し、100万ユーザー(およびそれを超える)のスパイクを容易に処理できます。 サービスは次のとおりです(一連のインタラクティブコンソールや、包括的なAPIセットからアクセスできます)。 AWS Elemental MediaConvert – OTT、ブロードキャスト、またはアーカイブのためのファイルベースのトランスコーディングサービスで、さまざまなフォーマットやコーデックをサポートします。 マルチチャンネルオーディオ、グラフィックオーバーレイ、クローズドキャプション、いくつかのDRMオプション機能をサポートしています。 AWS Elemental MediaLive – テレビやマルチスクリーンデバイスにリアルタイムでビデオストリームを配信するライブエンコーディングサービスです。エンコードパラメータを完全に制御しながら、信頼性の高いライブチャネルを数分で展開できます。 広告挿入、マルチチャンネルオーディオ、グラフィックオーバーレイ、クローズドキャプションをサポートしています。 AWS Elemental MediaPackage – オリジンサーバーとジャストインタイムパッケージのサービスです。 1つのビデオ入力から、複数のデバイスで視聴するために様々な形式のビデオ出力を生成します。 複数の収益モデル、タイムシフトライブストリーミング、広告挿入、DRM、ブラックアウト管理をサポートしています。 AWS Elemental MediaStore – Amazon Simple Storage Service(S3)の規模と耐久性を活用しながら、ライブストリーミングのような高性能かつ低遅延のアプリケーションで利用可能なメディア最適化ストレージサービスです。 AWS Elemental MediaTailor – 広告配信とサーバーサイド広告挿入、幅広いデバイス、トランスコード、サーバーサイドとクライアントサイドの広告挿入の正確なレポートをサポートする収益化サービスです。 以下のセクションでは、すべての機能をリストするのではなく、できるだけ多くのスクリーンショットをご紹介し、豊富な機能セットとこれら一連のサービスによって得られる設定をよりご理解いただけるように努めます。 AWS Elemental MediaConvert MediaConvertでは、ファイルに格納されているコンテンツをトランスコードすることができます。 個々のファイルやメディアライブラリ全体を処理することができます。コンテンツと目的の出力を指定する変換ジョブを作成し、それをMediaConvertに送信するだけです。これらはインストールやパッチ適用の必要がなく、納期やパフォーマンスに影響を与えずにニーズに合わせてサービス拡張できます。 MediaConvertのコンソールでは、出力プリセット、ジョブテンプレート、キュー、およびジョブを管理できます: ビルドインシステムのプリセットを使用することも、独自のプリセットを作成することもできます。 独自プリセットにより設定をフルコントロール可能です: ジョブテンプレートには名前が付けられ、1つ以上の出力グループが生成されます。クリックしてテンプレートに新しいグループを追加することができます: すべての準備が整ったら、いくつかの最終的な選択を行いジョブを作成するために「Create」をクリックします。 […]

Read More

DNS を使って AWS Certificate Manager の検証を簡単に

Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書はインターネット越しのネットワーク通信を安全にし、Web サイトの身元を確認するのに使われています。アマゾンは証明書を発行する前に、そのドメイン名をあなたが管理している事を検証しなければなりません。今回、あなたが管理しているドメイン名について SSL/TLS 証明書の発行リクエストを AWS Certificate Manager (ACM) にした際に、Domain Name System (DNS) 検証を使えるようになりました。これまで、ACM はEメール検証のみをサポートしており、ドメインの所有者は証明書発行リクエストのつどEメール受け取り、確認して承認する必要がありました。 DNS 検証では、そのドメインをあなたが管理している事を証明するために CNAME レコード を DNS 設定に書き込む必要があります。CNAME レコードの設定後は、DNS レコードが変更されない限り、有効期限切れ前には ACM は自動で DNS 検証した証明書を更新します。Amazon Route 53 で DNS を管理している場合は、ドメインの検証がより簡単になるよう ACM が DNS 設定の更新も行うことができます。このブログ記事では、DNS 検証を使って Web サイトの証明書リクエストを行う方法を紹介します。同等のステップを AWS CLI、AWS API、AWS SDK を使って行うには、AWS Certificate Manager in the AWS […]

Read More

Amazon EC2 Systems Manager による Microsoft VSS を使用したスナップショットサポート

私たちはここでWindows AMIを稼働させるAmazon EC2におけるMicrosoftボリュームシャドウコピー(VSS)のサポートをアナウンスできることを嬉しく思います。VSSはMicrosoft Windows(主要なSQL ServerやExchange Serverなどのマイクロソフトアプリケーションを含む互換性のある)環境における非常に一般的なボリュームバックアップ技術です。VSSはファイルの書き込みなどのディスク処理をバックアップ処理実行中も適切に管理するため、アプリケーション一貫性を持ったバックアップが可能となります。 アプリケーション一貫性バックアップは、マシンまたはインスタンスに接続されたボリュームのバックアップと同時に実行され、メモリ内のすべてのデータと処理中のすべてのトランザクションをキャプチャします。 VSSが有効なAmazon EBSボリュームのスナップショット(以降、”VSS有効化スナップショット”と表記) は、Amazon EC2 Systems ManagerのRun Commandから使用可能です。AWSEC2-CreateVssSnapshot コマンドによってWindowsインスタンスのEC2にアタッチされたEBSボリュームを、バックアップ処理の間トランザクションデータの一貫性を失うことなく、アプリケーション一貫性を持ったスナップショットを取得可能です。この機能によってSQL Backupや、カスタムスクリプトなどによって提供されたアプリケーション固有のバックアップソリューションは不要となります。さらに、イメージレベルバックアップにおけるアプリケーション一貫性を維持するためのサードパーティ製ツールも不要になります。 AWSEC2-CreateVssSnapshotの使用方法 VSS有効化スナップショットは、Windowsが稼働するEC2インスタンスに対してAWSEC2-CreateVssSnapshotコマンドをEC2 Systems Manager Run Commandから呼び出すことで実行します。AWS管理コンソールやAWS CLIから実行したり、PowerShellスクリプトやLambda関数から呼び出すことも可能です。本ブログではEC2コンソールからコマンドで実行する例を示します。 EC2管理コンソールで、AWSEC2-CreateVssSnapshotコマンドのドキュメントを選択し、VSS有効化スナップショットを取得したいEBSボリュームを持つインスタンスを選択します。 インスタンスを選択した後、スナップショットに追加したい説明やタグを設定します。ブートボリュームをスナップショット処理から除外することも可能です。 起動されるとRun CommandはVSSコンポーネント(詳細については後述)に対して、EC2 Windowsインスタンス上のVSS対応アプリケーションのすべての処理中のI/Oをコーディネーションするよう指示します。これによってI/OバッファはEBSボリュームに対してフラッシュされ、すべてのI/Oはスナップショット取得が完了するまでフリーズされます。この結果アプリケーション一貫性が維持されます。スナップショットが取得された後、I/Oフリーズが解除され通常処理に復帰します。 Run Commandやスクリプトから取得したスナップショットは、EC2コンソール左側のEBSスナップショットメニューで確認できます。 このプロセスで正常に取得された全てのVSS有効化スナップショットには “AppConsistent:True”というタグが付与されます。本機能についてのより詳細についてはこちらAWSEC2-CreateVssSnapshot のドキュメントを参照してください。 VSS有効化スナップショットを取得するためのEC2インスタンスの準備 インスタンスへのスナップショット許可 : IAMコンソールを開き、”Amazon EC2″サービスに対する以下の権限を許可する新しいポリシーを作成します。 DescribeInstances CreateTags CreateSnapshot またIAMコンソールからAmazon EC2ロールAmazonEC2RoleForSSMに対して上記で作成したポリシーを適用します。さらにこのロールを直接EC2 Windowsインスタンスにアタッチします。 VSSコンポーネントのインストール : VSSコンポーネント(AwsVssComponents)をAWS-ConfigureAWSPakageコマンドをSystems ManagerのRun Commandから呼び出してインストールする必要があります。 より詳しいVSS有効化スナップショット取得のためのEC2インスタンスのセットアップについてはこちらAmazon EC2 ドキュメントを参照ください。 AWSEC2-CreateVssSnapshot使用する際には、対象のEC2インスタンスに対してEBSスナップショット作成およびタグ書き込み許可のIAM許可が必要となります。コンプライアンスやポリシーの理由から追加のIAM許諾をインスタンスに付与したくない場合には、カスタム可能なサンプルのスクリプトを活用可能です。このスクリプトの詳細についてはこちらAWSEC2-ManageVssIOに関するドキュメントを参照して下さい。 VSS有効化スナップショットのリストアプロセスは通常のEBSスナップショットと同様です。こちらのリストアのサンプルスクリプトも使用できます。このリストア用スクリプトで、指定されたEBSスナップショットからEC2 Windowsインスタンスにリストアすることが可能です。 […]

Read More

Amazon QuickSight の更新 – 地理空間の可視化、プライベートVPCアクセス、その他

AWSでは記念日を敢えて祝うことはあまりしません。100近いサービスによって、週に何度もアップデートを展開するのが当たり前になっています。(まるで週に何度もケーキを食べて、シャンパンを飲んでいるようなものです。)それは楽しそうに聞こえますが、我々はむしろ、お客様に耳を傾け、イノベーションを起こすことに多くの時間を費やしています。とは言うものの、Amazon QuickSight は一般提供開始から1年が経ちましたので、簡単にアップデートを紹介したいと思います! QuickSight の事例 本日、数万のお客様(スタートアップからエンタープライズまで、交通や法律、鉱業、医療などの様々な業界)がお客様のビジネスデータの分析とレポートのためにQuickSightを利用されています。 幾つか例を上げましょう。 Gemini は負傷した労働者を弁護するカリフォルニア弁護士に法的根拠の調達サービスを提供しています。彼らは、カスタムレポートの作成や一度限りのクエリの実行から、ドリルダウンとフィルタリングを使用した動的なQuickSightダッシュボードの作成と共有までを行っています。QuickSightは、販売パイプラインの追跡、注文のスループットの測定、注文処理パイプラインでのボトルネックの特定に使用されています。 Jivochat はウェブサイト訪問者とウェブサイトの所有者とを繋ぐ、リアルタイムメッセージングプラットフォームを提供しています。QuickSightを使用して、彼らはインタラクティブなダッシュボードを作成・共有しながら、元となるデータセットへのアクセスも提供しています。これにより、静的なスプレッドシートを共有するにとどまらず、誰もが同じデータを見ていることを保証し、現時点でのデータに基づいてタイムリーな決定を下すことを後押ししています。 Transfix は、小売業、食品・飲料、製造業およびその他の業種のFortune 500に名を連ねるリテールの荷送主に、荷物にマッチする配送業者を選択でき、ロジスティクスの可視性を高める、オンライン貨物市場です。QuickSightはBIエンジニアと非技術系ビジネスユーザーの両方に分析環境を提供しています。彼らはQuickSightを通じて、輸送ルート、運送業者効率性、プロセス自動化などのビジネスの鍵となる事柄や運営指標を吟味しています。 振り返り / 先読み QuickSightに対するフィードバックはとても役に立っています。お客様は、自社のBIインフラを設定または実行することなく、従業員がQuickSightを使用してデータに接続し、分析を実行し、データに基づいた高速な決定を下すことができていると教えてくれます。我々は頂いたフィードバックをすべて歓迎し、それを使用してロードマップを推進し、1年で40を超える新機能を導入してきました。以下はその要約です: 2016年12月 – QuickSight Enterprise Edition. 2017年2月 – Amazon Athenaをサポート; SPICEデータの自動リフレッシュ予約 2017年4月 – KPIチャート, CSVエクスポート, ADコネクタ; US East(Ohio)で利用可能に; AWS CloudTrailによる監査ログに対応 2017年5月 – Presto と Apache Spark のコネクタ; SAML 2.0によるフェデレーションシングルサインオン 2017年6月 – Amazon Redshift Spectrumのサポート; 1-ClickでS3分析の可視化 2017年8月 – Asia Pacific […]

Read More

【変更版】11 月の AWS Black Belt オンラインセミナーのご案内

※11/20追記 直前のお知らせとなり申し訳ありません。11/21(火) 12:00-13:00に開催を予定しておりました「AWS上の位置情報」ですが、講師の都合により延期となりました。事前登録いただいておりました皆様、申し訳ございませんでした。また、改めて開催予定日を案内させていただきます。   こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー11月の配信についてご案内させて頂きます。初めてご紹介するNLB (Network Load Balancer) を中心としたELBのセッションをはじめ、今月も様々なテーマを取り扱います。 また今年もAWS re:Inventの開催期間中に現地からの生中継で最新アップデートをお伝えする回を予定しておりますので、こちらもぜひご登録いただければと思います。                   11月の開催予定 サービスカット 11/1(水) 18:00-19:00 Amazon EMR 11/15(水) 18:00-19:00 ELB Update – Network Load Balancer(NLB)と関連サービス 11/22(水) 18:00-19:00 AWS WAF – OWASP Top10脆弱性緩和策 – ソリューションカット 11/9(木) 12:00-13:00 Amazon Pinpoint で始めるモバイルアプリのグロースハック  ※ 通常の開催曜日と異なりますのでご注意ください 12/1(金) 12:00-13:00 […]

Read More

詳解: Amazon ECSのタスクネットワーク

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはコンテナにElastic Network InterfaceをアタッチできるようにするAmazon ECSのTask Networkingを発表しました。 この記事では、ECSが管理するインスタンス(コンテナインスタンスと呼ばれます)上でContainer Networking Interfaceプラグインを使って、この新しいコンテナネイティブなawsvpcネットワークモードがどのように実装されているかを詳しくご紹介したいと思います。 こちらはAmazon ECSでタスクネットワークが動作するかにdeep diveしたものです。もし自身のコンテナ化したアプリケーションでどうやってタスクネットワークを使い始めれば良いかについて学びたい時には、Amazon ECSコンテナにCloud Native Networkingが登場をご覧下さい。Cloud Native Computing Foundation (CNCF)がContainer Networking Interface (CNI)プロジェクトをホストしており、Linuxコンテナでネットワークインターフェースを設定するためのプラグインを書くための仕様やライブラリが含まれています。AWSのクラウドネイティブコンピューティングについての詳細は、Adrian CockcroftのCloud Native Computingについての投稿をご覧下さい。 コンテナインスタンスのセットアップ コンテナインスタンス上でのタスクネットワーク有効化の詳細をご説明する前に、ECSの典型的なインスタンスがどのようになっているかを見てみましょう。 上の図は典型的なコンテナインスタンスを示しています。ECS agentは自身もコンテナとして実行されているのですが、以下のような責任を負っています: EC2インスタンスをECSのバックエンドに登録 コンテナインスタンスに対してECSバックエンドが発生させたタスク状態の変化を、正しく適応 Dockerデーモンと会話しながら、コンテナの作成、開始、停止、監視 コンテナの状態とタスクの状態の遷移をECSバックエンドにリレー ECS agentはその管理下のコンテナのスーパーバイザーの様に動作するので、Dockerデーモン(Dockerのデフォルトネットワークモードで設定されたコンテナ用)、又はCNIプラグイン達(ネットワークモードがawsvpcで設定されたタスク内のコンテナ)のための、ネットワーク設定をする難しさをオフロードしてくれます。 いずれの場合にも、コンテナのネットワークスタックは、ネットワークのnamespaceを通じて設定されます。ip-netns(8)のマニュアルによると「ネットワークnamespaceは論理的なネットワークスタックのコピーで、自身のルーティング、ファイアウォールルール、ネットワークデバイスを持っています。」 とあります。ネットワークnamespaceの構成によって、ホスト上で動いているプロセスやコンテナ間でのネットワークスタックの隔離を可能としてくれます。 ネットワークnamespaceとCNIプラグイン CNIプラグインとは、CNI仕様を満たしコンテナのネットワーク接続性の設定を行う実行ファイル群です。CNIプロジェクトではプラグインの仕様を定義し、プラグインが利用するライブラリを提供することで、一貫していて信頼でき、かつ簡素なプラグイン用のインタフェースを提供してくれます。 コンテナやネットワークnamespaceを指定してプラグインを呼び出す時に、ADDコマンドでコンテナにネットワークインターフェースを追加したり、DELコマンドでそれを落としたりします。例えばリファレンスのBridgeプラグインは、ホストネットワークnamespaceの中にいるブリッジに対してホスト上の全てのコンテナを追加します。 このプラグインのモデルはECS agentの「コンテナのライフサイクルへの最小限の介入」というモデルと相性が良く、agentはコンテナのネットワーク設定の詳細について考慮する必要がなくなります。また拡張性の高いモデルなので、将来必要になった時には、agentが異なるプラグイン群を利用できるようにスイッチさせることもできます。最後に、これらプラグインは必要な時に呼び出されるだけなので、その死活監視をECS agentがする必要はありません。 ECS agentからCNIプラグインを呼び出す ECSがElastic Network Interfaceをインスタンスにアタッチし、agentに対しそのElastic Network Interfaceをタスク内のコンテナに対してプロビジョンするようにメッセージを送った時には、(任意のネットワークデバイスを使う) そのElastic […]

Read More

Amazon ECSコンテナにCloud Native Networkingが登場

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはAmazon ECSのTask Networkingを発表しました。これによって、Elastic Network Interfaceを使ったAmazon EC2のネットワーク機能をタスクに持ち込むことができるようになります。 Elastic Network InterfaceはVPC内のインスタンスにアタッチすることができる仮想的なネットワークインタフェースです。EC2の仮想マシンを起動する時には、インスタンスにネットワークの機能を提供するために自動的に1つのElastic Network Interfaceがプロビジョンされます。 タスクは実行されるコンテナの論理的なグループです。これまでは、Amazon ECSで実行されるタスクはそれが動くEC2ホストのElastic Network Interfaceを共有していました。これからは、新しいawsvpcというネットワークモードを使うことで、Elastic Network Interfaceが直接タスクにアタッチされます。 これによってネットワークの設定を簡略化することができ、VPCが持っているネットワークの全機能、隔離性、そしてセキュリティの制御を各コンテナにEC2インスタンスと同様のレベルで利用することができます。 この記事では、awsvpcモードがどのように動作し、ECSのタスクでどのようにElastic Network Interfaceを使い始めることができるかをご紹介します。 背景: EC2のElastic Network Interface VPC内にEC2インスタンスを起動する時には、各インスタンスが互いに通信できるようにするために、追加のオーバーレイネットワークを設定する必要はありません。標準で、VPCのルーティングテーブルがインスタンスや他のエンドポイント間での通信をシームレスに実現してくれます。これは、Elastic Network Interfaceと呼ばれるVPC内の仮想的なネットワーク・インタフェースによって可能となっています。全ての起動されるEC2インスタンスは自動的に1つのElastic Network Interface(プライマリネットワークインタフェース)がアサインされます。サブネット、セキュリティグループといった全てのネットワークパラメータは、このプライマリネットワークインタフェースの属性として扱われます。 さらに、各Elastic Network Interfaceは作成時にVPCによってIPv4アドレス(プライマリIPv4アドレス)が割当られます。このプライマリアドレスはユニークでVPC内でルーティング可能なものです。これによって、VPCは実際はフラットなネットワークとなり、ネットワークトポロジを簡潔なものとしてくれます。 Elastic Network InterfaceはVPC上で多様なエンドポイントとの接続を実現するための基本的なビルディングブロックとみなすことができ、そのうえでより高レベルな抽象レイヤを構築することができます。これによってElastic Network Interfacdeは以下の機能を利用することが可能となっています: VPCネイティブなIPv4アドレスとルーティング (VPC上でのインスタンス間や他のエンドポイントとの間) ネットワークトラフィックの隔離 ACLとファイアウォールルール(セキュリティグループ)を使ったネットワークポリシーの強制 (サブネットのCIDRを通じた)IPv4アドレスレンジの強制 なぜawsvpcを使うのか? 以前はECSはDockerが提供する標準のネットワークの挙動が提供するネットワーク機能に依存した形でコンテナ向けのネットワークスタックを構成していました。デフォルトのBridgeネットワークモードでは、インスタンス上のコンテナ達はdocker0ブリッジを使って互いにつながっています。インスタンス外のエンドポイントと通信する時には、コンテナはこのブリッジを利用し、それが実行されているインスタンスのプライマリネットワークインタフェースを使います。コンテナは、ファイアウォールルール(セキュリティグループ)やIPアドレスは、そのプライマリElastic Network Interfaceのネットワーク属性を共有しまた依存しています。 これは、Dockerによって割当られたIPアドレス(ローカルスコープのアドレスプールから割当られます)を使ってもこれらのコンテナに到達できないことと、細かいNetwork ACLやファイアウォールルールを強制できないことを意味します。代わりに、VPCからはインスタンスのプライマリElastic Network […]

Read More

12 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。プロフェッショナル サービスの宮本です。AWS Black Belt オンラインセミナー12月の配信についてご案内させて頂きます。サービスカットは、10/24 に Generally Available を迎えた Amazon Aurora with PostgreSQL Compatibility をはじめ、今月も様々なテーマを取り扱います。また、ソリューションカットは、「AWSサービスを利用したアプリケーション開発を始めよう」と題して、AWSにおけるアプリケーション開発に活用できる様々なサービスについてご紹介や、AWSにおけるIPv6のサポート状況についてご紹介します。                         12月の開催予定 サービスカット 12/6(水) 18:00-19:00 Amazon Elasticsearch Service 12/14(木) 18:00-19:00 Amazon ElastiCache ※ 通常の開催曜日と異なりますのでご注意ください。 12/20(水) 18:00-19:00 Aurora PostgreSQL ソリューションカット 12/1(金) 12:00-13:00 AWS re:Invent 2017 Report  ※ 通常の開催曜日と異なりますのでご注意ください。 12/5(火) 12:00-13:00 […]

Read More

Amazon Aurora Under the Hood: クオーラムメンバーシップ

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。 この記事は、Amazon Auroraがどのようにクオーラムを使用するのかをお話する4回シリーズの最後です。最初の記事では、障害が発生した場合に必要なクォーラムのメリットとメンバの最小数について説明しました。2回目の記事では、読み書きを行う際に利用するネットワーク帯域の増加を避けるために、ロギング、キャッシュの状態、および非破壊的な書き込みを使用する方法について説明しました。3回目の記事では、より高度なクォーラムモデルを使用して複製コストを削減する方法について説明しました。クォーラムに関するこの最後の記事では、クォーラムメンバーシップの変更を管理する際にAmazon Auroraが問題を回避する方法について説明します。 クオーラムメンバーシップの変更を管理するテクニック マシンは故障します。クオーラムメンバの1つが破損すると、ノードを交換することによってクオーラムを修復する必要があります。これは複雑な決定になります。 クォーラムの他のメンバーは、障害のあるメンバに一時的なレイテンシーの増加が発生したか、再起動のための短期間の可用性低下が発生したか、または永久にダウンしたかどうかを判断できません。 ネットワークパーティションにより、複数のメンバーグループが同時にお互いに隔離を実行出来ます。 ノードごとに大量の永続状態を管理している場合、クォーラムを修復するための状態の再複製には長い時間がかかります。 そのような場合、障害のあるメンバーが復帰できる場合に備えて修復を開始することについて慎重に行う必要があります。 多くのノードで状態をセグメント化することで、修復時間を最適化することができます。 しかし、これは失敗の可能性を高めます。 Auroraでは、データベースボリュームを10GBのチャンクに分割し、3つのアベイラビリティゾーン(AZ)に分散した6つのコピーを使用します。 現在の最大データベースサイズが64TBなので、プロテクショングループは6,400個、セグメント数は38,400個です。 このスケールでは破損は一般的に発生する可能性があります。 メンバーシップの変更を管理する一般的な方法は、一定期間リースを使用し、各リースでメンバーシップを確保するためにPaxosなどのコンセンサスプロトコルを使用することです。 しかし、Paxosは処理負荷のかかるプロトコルであり、最適化されたバージョンでは多数の障害が発生します。 障害を管理するためにクオーラムセットを利用する Auroraはメンバーシップの変更を管理するために、ロギング、ロールバック、コミットなどのクォーラムセットとデータベース技術を使用します。 A、B、C、D、E、Fの6つのセグメントを持つプロテクショングループを考えてみましょう。この場合、書き込みクォーラムはこの6組のうち4つのメンバーであり、読み取りクォーラムは3つのメンバーです。 前回の記事でご紹介したように、Auroraのクオーラムはこれよりも複雑ですが、今は単純に考えてみることにします。 Auroraの読み書きはそれぞれ、メンバーシップエポックを使用します。これは、メンバーシップの変更ごとに単調に増加する値です。 現在のメンバーシップエポックよりも古いエポックにある読み取りと書き込みは拒否されます。そのような場合、クオーラムメンバーシップの状態をリフレッシュする必要があります。 これは、概念的には、REDOログ内のlog sequence numbers(LSN)の概念に似ています。 エポックナンバーおよび関連する変更記録は、メンバーシップに順序付けられたシーケンスを提供します。 メンバーシップエポックを変更するには、データ書き込みと同様に書き込みクォーラムを満たす必要があります。 現在のメンバーシップの読み込みには、データの読み込みと同様のリードクオーラムが必要です。 ABCDEFのプロテクショングループの話を続けましょう。セグメントFが破損した可能性があるとし、新しいセグメントGを導入する必要があると考えてください。一時的な障害に遭遇する可能性があり、迅速に復帰する可能性があります。またはリクエストを処理しているかもしれませんが、なんらかの理由で検出出来ない可能性があります。また、Fが復活したかどうかを確認するのを待ちたくはありません。クオーラムが損なわれて2回目の障害が発生する可能性が増加だけです。 これを解決するためにクォーラムセットを使用します。 私たちはABCDEFからABCDEGに直接メンバーシップの変更をすることはありません。代わりに、メンバーシップのエポックを増やし、クォーラムセットをABCDEFとABCDEGに移動します。書き込みはABCDEFの6つのコピーのうち4つから正常に行われなければならず、またABCDEGの6つのコピーのうち4つからackが返る必要があります。 ABCDEのどの4つのメンバーは両方とも書き込みクォーラムを満たしています。 読み取り/修復クォーラムは同じように動作し、ABCDEFからの3つのackとABCDEGから3つのackが必要です。ABCDEからの3つのいずれかが両方を満たします。 データがノードG上に完全に移動され、Fを取り除くと決定した場合、メンバーシップエポックの変更を行い、クォーラムセットをABCDEGに変更します。エポックの使用は、コミットLSNがREDO処理のために行うのと同様に、これをアトミックに行います。このエポックの変更は、現在の書き込みクォーラムが満たされている必要があり、他のアップデートと同様に、ABCDEFの6つのうち4つと、ABCDEGの6つのうちの4つからのackが必要です。Gが利用可能になり前に再びノードFが利用可能になると、変更を元に戻しメンバーシップエポックの変更をABCDEFに戻します。完全に健全なクオーラムに戻るまで、いかなる状態やセグメントも破棄しません。 このクォーラムへの読み書きは、メンバーシップの変更中に、変更前または変更後と同じように行われることに注意してください。 クォーラムメンバーシップへの変更は、読み取りまたは書き込みをブロックしません。失効したメンバーシップ情報を持つ呼び出し元は、状態をリフレッシュして正しいクォーラムセットに要求を再発行します。また、クオーラムメンバーシップの変更は、読み取り操作と書き込み操作の両方に対して非ブロッキングです。 もちろん、Fの代わりにGへデータを移動しクオーラムを修復している間にABCDEGのいずれかが破損する可能性もあります。多くのメンバーシップ変更プロトコルはメンバーシップの変更中に障害を柔軟に処理しません。クォーラムセットとエポックでは、簡単です。Eも破損してHに置き換えられる場合を考えてみましょう。ABCDEFとABCDEGとABCDFHとABCDGHのクオーラムに移動するだけです。単一障害と同様に、ABCDへの書き込みはこれらのすべてを満たします。メンバーシップの変更は、読み取りと書き込みの失敗と同じ範囲になります。 まとめ クォーラムセットをメンバーシップの変更に使用することにより、Auroraは小さなセグメントを使用することができます。これにより、Mean Time To Repair(MTTR)および複数の障害に対する可能性を削減することで、耐久性が向上します。また、お客様のコストを削減します。Auroraのボリュームは必要に応じて自動的に増加し、小さなセグメントでは少しずつ増加します。クォーラムセットを使用することで、メンバーシップの変更が行われている間も読み取りと書き込みが継続できるようになります。 メンバーシップの決定を元に戻すことができれば、積極的にクオーラムを変更することができます。障害のあったメンバーが返ってくると、いつでも変更を元に戻すことができます。いくつかの他のシステムでは、リースが期限切れとなり、クオーラムメンバシップを再確立する必要があるため、定期的な停止が発生します。Auroraは、リースが期限切れになるまでメンバーシップの変更操作を延期するという耐久性の犠牲を払わず、クオーラムメンバシップが確立されている間に読み込み、書き込み、またはコミットを遅らせるというパフォーマンス上のペナルティも発生しません。 Auroraは、さまざまな分野で進歩を遂げています。データベースと分散システムを統合するアプローチは、これらの多くの中核を成しています。クォーラムをどのように使用するかについてのこの連載をご覧いただき、ご自身のアプリケーションやシステムを設計する方法について考えるときに役立てて頂けると思います。今回使用した手法は広く適用可能ですが、スタックの多くの要素にに対して適用する必要があります。 もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。 翻訳は星野が担当しました (原文はこちら)

Read More

In the Research Spotlight: Zornitsa Kozareva

これは、ドイツのポツダム市にある Hasso-Plattner-Institut の Haojin Yang、Martin Fritzsche、Christian Bartz、Christoph Meinel 各氏によるゲスト投稿です。低パワーデバイスでのディープラーニングの実際の実装に関する研究を見るのはわくわくします。この作業は、強力で知的な機能を毎日の生活に拡大するうえで重要な役割を果たします。 近年、ディープラーニングテクノロジは非常に優れたパフォーマンスと多くのブレークスルーを学会と業界の両方で達成しています。しかし、最新鋭のディープモデルは計算コストが高く、大きなストレージ容量を消費します。ディープラーニングは、モバイルプラットフォーム、ウェアラブルデバイス、自律ロボット、IoT デバイスなどの領域で多数のアプリケーションによって強く要求されています。このような低パワーデバイスにおいてディープモデルをどのように効率的に適用するかが課題となります。 最近提案されたバイナリニューラルネットワーク (BNN) は、標準の算術演算ではなくビット単位演算を提供することで、メモリサイズとアクセスを大幅に減らします。最新鋭のディープラーニングモデルは、実行時に効率を大幅に向上させ、エネルギー消費を低くすることで、低パワーデバイスで実装することができます。この手法を開発者フレンドリーな OpenCL と組み合わせることで (VHDL/Verilog と比較した場合)、FPGA がディープラーニング用の実行可能なオプションとなります。 この投稿では、BMXNet についてご紹介します。これは Apache MXNet に基づくオープンソースの BNN (バイナリニューラルネットワーク) です。開発された BNN レイヤーは他の標準ライブラリコンポーネントにシームレスに適用でき、GPU および CPU モードの両方で機能します。BMXNet は Hasso Plattner Institute のマルチメディア研究グループによって管理、開発され、Apache ライセンスに基づいてリリースされています。このライブラリ、いくつかのサンプルプロジェクト、およびトレーニング済みバイナリモデルのコレクションは、https://github.com/hpi-xnor からダウンロードして入手可能です。 フレームワーク BMXNet は、入力データと重みのバイナリ化をサポートするアクティベーション、畳み込み、および完全に接続されたレイヤーを提供します。これらのレイヤーは、対応する MXNet バリアントに対するドロップインリプレースメントとして設計されていて、QActivation、QConvolution、および QFullyConnected と呼ばれます。さらに、レイヤーによって計算されるビット幅を制御する追加のパラメータ act_bit を提供します。MXNet と比較した、提案のバイナリレイヤーの Python での使用例をリスト 1 およびリスト 2 に示します。当社は、ネットワークの最初のレイヤーおよび最後のレイヤーにバイナリレイヤーは使用しません。使用すると正確性が大幅に低下する可能性があるためです。BMXNet […]

Read More