Amazon Web Services ブログ

Category: News

NoSQL Workbench for Amazon DynamoDB – プレビューの使用が可能になりました

毎月数件のリクエストから毎秒何千万ものリクエストに簡単にスケールできる、完全マネージド型の key-value データベースとドキュメントデータベースを AWS のお客様に提供する Amazon DynamoDB には、いつも感銘を受けてきました。 DynamoDB チームは最近、オンデマンドキャパシティからネイティブな ACID トランザクションのサポートまで、数多くの素晴らしい機能をリリースしました。こちらは、グローバルテーブル、ポイントインタイムリカバリ、およびインスタントアダプティブキャパシティなど、最近の DynamoDB 発表の内容がよくわかる概要です。DynamoDB は、保管時のお客様データをすべてデフォルトで暗号化するようになりました。 しかし、リレーショナルデータベースから NoSQL への発想の切り替えはそれほど簡単なことではありません。昨年の re:Invent では、DynamoDB の仕組みと、それをどのように皆さんのユースケースに使用できるかに関する 2 つの素晴らしい講演が行われました。 Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (講演者: Jaso Sorenson) Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (講演者: Rick Houlihan) DynamoDB をさらに役立てていただくため、AWS は本日、プレビュー版の NoSQL Workbench for Amazon […]

Read More

追加のメタデータを使用した VPC フローログから学ぶ

Amazon Virtual Private Cloud のフローログでは、VPC のネットワークインターフェイスを出入りする IP トラフィックに関する情報を取得することができます。フローログのデータは、Amazon CloudWatch Logs またはAmazon Simple Storage Service (S3) に発行できます。 2015 年にVPC フローログを開始したため、VPC 全体の接続性の問題、侵入の検出、以上の検出、またはコンプライアンスの目的でのアーカイブをトラブルシューティングするなどのさまざまなユースケースにそれを使用してきました。今日まで、VPC フローログは、ソース IP、ソースポート、宛先 IP、宛先ポート、アクション (accept、reject) およびステータスなどの情報を提供します。VPC フローログは一度有効になると、エントリは、次のようになります。 この情報はほとんどのフローを理解するのに十分であった一方で、IP アドレスをインスタンス ID に一致させるため、またはフローの方向性を推測して意味のある結論を得るために、追加の計算と検索が必要でした。 今日、ネットワークフローをより良く理解するために、フローログレコードに含めるために、追加メタデータの可用性を通知しています。豊かなフローログにより、ログデータから意味のある情報を抽出するために必要な計算やルックアップの回数を減らすことで、スクリプトを簡素化し、後処理の必要性を完全に排除することができます。 新しい VPC フローログを作成するときに、既存のフィールドに加えて、次のメタデータを追加することができるようになりました。 vpc-id : ソース Elastic Network Interface (ENI) を含む VPC の ID。 subnet-id : ソース ENI を含むサブネットの ID。 instance-id : ソースインターフェイスに関連付けられたインスタンスの Amazon […]

Read More

Amazon Quantum Ledger Database (QLDB) が利用可能に

データ型、クエリモデル、インデックスオプション、スケーリングの期待値、パフォーマンス要件を幅広く考慮した場合、データベースは 1 つのサイズですべての製品に合わせることはできません。こうした理由から AWS データベースは多くの種類があり、それぞれが異なる種類のアプリケーションのニーズを満たすように作られています。 QLDB の紹介 本日は、AWS データベースファミリーの最新メンバーである Amazon QLDB についてお話ししたいと思います。最初に 2018 年の AWS re:Invent で発表され、プレビュー形式で利用可能でしたが、5 つの AWS リージョンにおいて本番形式で利用できるようになりました。 QLDB は台帳データベースとして、​​保存したデータの信頼できるデータソース (レコードのシステム として知られる) を提供するように設計されています。更新、変更、または変更不可のデータにコミットされたすべての変更において完全かつ不変の履歴を保持します。QLDB は履歴データへの PartiQL SQL クエリをサポートし、履歴が正確かつ正当であることを暗号で検証できる API も提供します。これらの機能により、QLDB は銀行や金融、e コマース、輸送や物流、人事や給与、製造、政府機関のアプリケーションや、保存したデータの整合性と履歴を維持する必要のあるその他の多くのユースケースに大変適しています。 重要な QLDB の概念 詳しく見ていく前に、最も重要な QLDB の概念を確認しましょう。 台帳 – QLDB 台帳は QLDB テーブルのセットと、テーブルに対する変更の完全かつ変更不可の履歴を保持するジャーナルで構成されます。台帳には名前があり、タグを付けることができます。 ジャーナル – ジャーナルはブロックのシーケンスで構成され、各ブロックは暗号化されて前のブロックにチェーンされているため、変更を検証できます。一方、ブロックにはテーブルに加えられた実際の変更が含まれ、効率的に取得できるようインデックスが付けられています。この追加専用モデルにより、以前のデータを編集または削除できなくなり、台帳が変更不可となります。QLDB を使用すると、ジャーナルのすべてまたは一部を S3 にエクスポートできます。 テーブル – テーブルは台帳内に存在し、ドキュメント改訂のコレクションが含まれます。テーブルは、ドキュメントフィールドのオプションのインデックスをサポートしています。インデックスは、等式 (=) […]

Read More

コンテナとコンテナ化されたアプリケーションに対する運用上の洞察

コンテナ化されたアプリケーションとマイクロサービスの適応が増えるに従い、監視と管理の負担がますます増えます。ビルダには Amazon Elastic Compute Cloud (EC2) のインスタンスなどのより長期にわたるインフラすトラクタに使用されるため、同じレベルの監視が期待され、要求されています。対照的に、コンテナは比較的短命で、通常は継続的なデプロイが求められます。これにより、信頼性をもって監視データを収集し、パフォーマンスやその他の問題を分析することが困難になり、このことが修復時間に影響を与えます。さらに、ビルダはさまざまなツールを使用してこの分析と検査を実行し、一連のインフラストラクチャとアプリケーションのメトリック、ログ、およびその他のトレース全体でコンテキストを手動で関連付ける必要があります。 Amazon CloudWatch Container Insights の一般的な利用状況の通知 本年 7 月に開催されたニューヨークの AWS Summit で、Amazon CloudWatch Container Insights のAmazon ECS および AWS Fargate のサポートは、新しいクラスタに対するオープンプレビューとして発表されました。本日より、Container Insights は既存のクラスタも監視する機能が追加されて、一般に利用可能になります。コンテナ管理サービスから、新規および既存のクラスタインフラストラクチャとコンテナ化されたアプリケーションの両方のコンピューティング使用率と障害に関する即時の分析情報を簡単に取得できます。これは、Kubernetes、Amazon Elastic Container Service for Kubernetes、Amazon ECS、および AWS Fargateが含まれます。 Amazon CloudWatch が一度有効になると、クラスタで実行中のすべてのコンテナを検出し、コンテナスタックの各レイヤのパフォーマンスと運用データを収集します。また、環境の変化に応じて継続的に監視と更新を行い、コンテナのメトリックとログの収集、監視、行動、分析に必要なツールの数を簡素化し、完全なエンドツーエンドの可視性を提供します。 このデータに簡単にアクセスできるということは、顧客が開発者の生産性の向上に焦点を移し、ダッシュボードを管理および構築するメカニズムの構築から離れることを意味します。 Amazon CloudWatch Container Insights の開始方法 ドキュメントの手順に従い、Container Insightsを有効にできます。一度有効になると、新しいクラスタが開始され、自分のリージョンのCloudWatch コンソールにアクセスすると、利用可能なダッシュボードのリストの中に Container Insights のオプションが表示されます。 これをクリックすると関連するダッシュボードに移動し、そこで観察対象となるクラスタをホストするコンテナ管理サービスを選択できます。 下の画像では、AWS Fargate […]

Read More

新機能: AWS Global Accelerator でのクライアント IP アドレス保持

AWS Global Accelerator は、着信するトラフィックを複数の AWS リージョンにルーティングするネットワークサービスです。これにより、グローバルなアプリケーションのパフォーマンスと可用性を向上させることができます。このサービスでは、当社が集積したエッジロケーションや遅延のないグローバルネットワークを利用することで、アプリケーション やネットワークの健全性、ユーザーの地理的位置などに基づき、トラフィック配信ができます。また、複数の AWS ロケーションからアナウンスされた静的な Anycast IP も使用できます (さらに詳しい情報は「New – AWS Global Accelerator for Availability and Performance」をご参照ください。 ) 。着信した TCP もしくは UDP トラフィックは、Application Load Balancer、Network Load Balancer、 Elastic IP Address にルーティングすることが可能です。 クライアント IP アドレス保持機能 当社は本日、AWS Global Accelerator に新たに加わった重要な機能について発表いたします。Application Load Balancer にトラフィックをルーティングしているお客様は、今後、ユーザーのクライアント IP アドレスを使い、エンドポイント上でのコード実行が行えるようになりました。この機能を使うと、特定の IP アドレス向けの処理を適用することができます。たとえば、IP アドレスに基づきフィルタリングを行うセキュリティグループの使用や、ユーザーの IP アドレスや所在地に応じた、カスタムコンテンツの提供などが行えます。加えて、ユーザーの所在地の地理的分布に関する統計情報を、IP アドレスを使いより精密に収集することも可能です。 クライアント IP […]

Read More

AWS System Manager Sessions Manager を使用した新しい機能 – Port Forwarding

昨今不変のインフラストラクチャアーキテクチャパターンを採用しているお客様が増えており、更新ごとにインフラストラクチャ全体を再構築およびリデプロイしています。SSH や RDP を介してサーバーに接続して、設定を更新したり、ソフトウェアの更新をデプロイしたりすることはほとんどありません。ただし、既存のアプリケーションをクラウドに移行する場合、Amazon Elastic Compute Cloud (EC2) インスタンスに接続して、さまざまな管理タスクまたは運用タスクを実行するのが一般的です。攻撃にさらされる面を減らすために、AWS では、ジャンプホストとも呼ばれる Bastion ホストを使用することをお勧めします。この特別な目的の EC2 インスタンスは、インターネットからのプライマリアクセスポイントになるように設計されており、他の EC2 インスタンスへのプロキシとして機能します。 EC2 インスタンスに接続するには、まず Bastion ホストに SSH/RDP 接続し、そこから宛先の EC2 インスタンスに接続します。 攻撃にさらされる面、Bastion ホストを管理するための運用上の負荷、および発生する追加コストをさらに削減するために、AWS Systems Manager Session Manager は、独自の Bastion ホストを実行および操作する必要も、 EC2 インスタンスで SSH を実行する必要もなく、 EC2 インスタンスに安全に接続できます。インスタンスに Systems Manager のエージェントがインストールされており、Systems Manager API を呼び出す IAM アクセス許可がある場合、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用して、Linux または Windows EC2 […]

Read More

Amazon Forecast が一般公開されました

履歴データを基に正確な時系列予測を得るのは、たやすい作業とは言えません。当社は昨年の re:Invent において Amazon Forecast を発表しました。これは、機械学習についてまったく経験がない人でも高い精度の予測をすることができる、完全マネージド型のサービスです。 その Amazon Forecast が一般公開されたことを、本日お伝えできるのは非常に喜ばしいことです。 Amazon Forecast では、サーバーのプロビジョニングは必要ありません。 これに必要なのは、履歴データ、そして予測結果に影響がありそうなメタデータを追加で揃えることだけです。たとえば、入手するか製造しようとしている特定の製品に関する需要は、天候、季節、そしてその製品が使用される土地などにより、おそらく変わってくるでしょう。 Amazon Forecast は、Amazon で使われているものと同じテクノロジーをベースにしており、スケーラブルで高い精度を持つ予測技術を使いやすく構築および運用するための、長年の経験を詰め込んだものとなっています。これは複数のデータセットを基に深層学習 を行い、多様なアルゴリズムを自動的に切り替えて使用するので、製品需要、クラウドのコンピューティング使用量、財務計画、サプライチェーン管理システムでのリソース管理など多くのユースケースに対応できます。 Amazon Forecast を使ってみる 今回の記事では、いくつかのサンプルデータを利用します。興味深いユースケースが良いので、今回はUCI の機械学習レポジトリが提供する、個別家庭の電力消費データセットを使うことにします。作業を簡単にするため、時間ごとのデータが CSV 形式のファイルに集められたバージョンを使っていきます。次に示すのはこのデータの最初の数行で、ここにはタイムスタンプ、電力消費量、クライアント ID が記述されています。 2014-01-01 01:00:00,38.34991708126038,client_12 2014-01-01 02:00:00,33.5820895522388,client_12 2014-01-01 03:00:00,34.41127694859037,client_12 2014-01-01 04:00:00,39.800995024875625,client_12 2014-01-01 05:00:00,41.044776119402975,client_12 それでは、Amazon Forecast コンソールを使いながら、予測子の構築と予測値の取得がいかに簡単かを確かめてみましょう。より進んだユーザーのためのオプションは、Jupyter ノートブックと AWS SDK for Python から利用できます。この GitHub レポジトリにサンプルのノートブックがいくつかあります。 Amazon Forecast コンソールで先ず最初に行うステップは、データセットグループの作成です。データセットグループは、お互いに関連のあるデータのためのコンテナーとして機能します。 データセットグループに合わせて、[Forecasting domain] から一つを選択します。各ドメインは、小売り、在庫計画、ウェブのトラフィックなど、それぞれ特定のユースケースに対応しています。また、そのトレーニングに使われたデータ形式を基にしたデータセットタイプを使用します。今回は、帰属するカテゴリーがないすべてのユースケースをカバーしている、[Custom] ドメインを使用しましょう。 次に行うのは、データセットの作成です。今アップロードしようとしているデータは時間ごとに集められたものですので、[Frequency […]

Read More

AWS が支えた Amazon プライムデー 2019

プライムデーに何を買いましたか? 私は、34 インチ Alienware Gaming Monitor を購入し、過去 6 年間よく役立ってくれた 25 インチのモニターのペアと交換しました。   過去何年もやってきたように、AWS がお客様のためにプライムデーを実現させた多くの方法のいくつかを共有したいと考えています。How AWS Powered Amazon’s Biggest Day Ever と Prime Day 2017 – Powered by AWS を読んで、それぞれのプライムデーの結果を評価する方法の詳細、その結果を利用して当社がシステムとプロセスの改善をどのように推進しているかを学んでください。 今年は、プライムデーで AWS が記録的な量のトラフィックと販売をサポートするのに役立った 3 つの方法 (Amazon Prime Video Infrastructure、AWS Database Infrastructure、Amazon Compute Infrastructure) に焦点を当てたいと考えています。それぞれを詳しく見ていきましょう… Amazon Prime Video Infrastructure Amazon プライムのメンバーは、2019 年 7 月 10 日に 2 […]

Read More

Amplify コンソール – フルスタックのサーバーレスウェブアプリのためのホスティング

AWS Amplify コンソールはフルスタックウェブアプリケーションのホスティングサービスで、使用したいソースコードリポジトリからの継続的なデプロイメントが可能です。Amplify コンソールは、2018 年 11 月に AWS re:Invent で発表されました。それ以来、チームはお客様のフィードバックに耳を傾け、迅速にイテレーションを行って 新しい機能をいくつかリリースしました。以下はそれらの簡単な要約です。 キャッシュの即時無効化 Amplify コンソールでは、コンテンツ配信ネットワーク、つまり CDN を介して、サーバーレスバックエンドを使用する単一ページのウェブアプリ、または静的サイトをホストすることができます。CDN は、世界中のエッジロケーションでファイルをキャッシュする分散されたサーバーのネットワークで、ウェブファイルアセットの低レイテンシー分散を可能にします。 これまで、CDN でコンテンツを更新するには、キャッシュを手動で無効化し、変更がグローバルに伝播されるまで 15~20 分待つ必要がありました。頻繁な更新を行うために、開発者はアセットヘッダーに短い TTL (time-to-live) を設定する (これによって更新は速くなりますが、パフォーマンスには悪影響が生じます) などの次善策を講じていましたが、今では、より迅速なデプロイメントとより高速なパフォーマンスの間で妥協する必要はありません。Amplify コンソールは、リポジトリに対するコミットコードごとに変更を構築して CDN にデプロイし、これらはブラウザで即時に表示できます。 「Deploy To Amplify Console」ボタン GitHub でプロジェクトソースコードをパブリッシュするときは、Readme ドキュメントに「Deploy To Amplify Console」ボタンを提供することによって、他の開発者がアプリケーションを簡単に構築してデプロイできるようにすることが可能です。ボタンをクリックすると Amplify コンソールが開き、コードをデプロイするための 3 つのステップのプロセスを提案します。 このプロセスをこれらのプロジェクト例でテストして、こちらのドキュメントも参照してください。独自のコードリポジトリへのボタンの追加は簡単で、この行を Readme ドキュメントに追加するだけです (GitHub URL の username と repository の名前を置き換えるようにしてください)。 [![amplifybutton](https://oneclick.amplifyapp.com/button.svg)](https://console.aws.amazon.com/amplify/home#/deploy?repo=https://github.com/username/repository) 手動でのデプロイメント […]

Read More

新着 – カーネルパニックをトリガーし、応答しない EC2 インスタンスを診断

オンプレミスのデータセンターにデプロイされたシステムで作業を行っていたころ、ときどき、応答しないサーバーのデバッグをしなければならないことがありました。その場合、通常は誰かに頼んで、フリーズしたサーバーでマスク不可能割り込み (NMI、non-maskable interrupt) ボタンを物理的に押してもらうか、あるいはシリアルインターフェイス (はい、シリアルです。RS-232 など) を介してコマンドコントローラーに信号を送信してもらう必要がありました。このコマンドによってシステムがトリガーされ、フリーズしたカーネルの状態がファイルにダンプされて、さらなる分析が行われます。このようなファイルは通常、コアダンプあるいはクラッシュダンプと呼ばれます。クラッシュダンプには、クラッシュしたプロセスのメモリのイメージ、システムレジスター、プログラムカウンター、その他フリーズの主要因を特定するのに役立つ情報が含まれています。 本日発表された新しい Amazon Elastic Compute Cloud (EC2) API を使うと、EC2 インスタンスでのカーネルパニックの生成を、リモートでトリガーすることができます。EC2:SendDiagnosticInterrupt API は、物理マシンで NMI ボタンを押す場合と同様に、診断割り込みを、実行中の EC2 インスタンスに送信します。それにより、インスタンスのハイパーバイザーがマスク不可能割り込み (NMI、non-maskable interrupt) をオペレーティングシステムに送信します。NMI 割り込みを受信したときのオペレーティングシステムの挙動は、システムの設定に依存します。通常はカーネルパニックの状態に入ります。カーネルパニックの挙動もオペレーティングシステムの設定に依存し、クラッシュダンプデータファイルの生成がトリガーされたり、バックトレースが取得されたり、差し替えのカーネルがロードされたり、システムが再起動されたりします。 組織内でこの API を使用できる人を管理するには IAM ポリシーを使用します。以下に例を示します。 クラウドエンジニアやシステムエンジニア、あるいはカーネル診断やデバッグ作業のスペシャリストが、クラッシュダンプの中からカーネルがフリーズした原因を分析するための非常に重要な情報を見つけ出します。ダンプを調べるときは、WinDbg (Windows) や crash (Linux) といったツールを使用します。 診断割り込みの使用 この API の使用プロセスは、3 つのステップからなります。まず、割り込みを受信したときの OS の挙動を設定しておく必要があります。 Windows Server AMI のメモリダンプは、デフォルトですでにオンの状態になっています。メモリダンプが保存された後の自動再起動も選択されています。メモリダンプファイルのデフォルトの場所は %SystemRoot% です。これは C:\Windows に相当します。 これらのオプションには、次の場所に進むとアクセスできます。 スタート > […]

Read More