Amazon Web Services ブログ

Amazon GuardDuty を使用して AWS アカウントとワークロードを保護すると、大量のデータをすばやく検索して可視化できるようになります。企業によっては、何千ものアカウントからアクティビティを分析しているところもあるでしょう。分析後、是正措置がとれるようにセキュリティチームに警告する必要があります。重要なのは、タイミングです。 GuardDuty に、Amazon Elasticsearch Service とデータの可視化を組み合わせることで、データを実用的な洞察に変換することができます。この記事では、Amazon ES を使用して GuardDuty の調査結果を分析する方法を示します。また、Amazon ES のオープンソースのデータ可視化プラグインである Kibana を使用して、データを検索、探索、可視化する方法を紹介します。 このようなリソースの作成を開始するための概要と手順は、次のとおりです。 ソリューションの概要と前提条件 設定方法の高水準フローは、以下に示すように次のステップから構成されています。 Amazon Cloudwatch Events と AWS Lambda を使用して GuardDuty の調査結果を収集します。それを Amazon S3 に送信します。 S3 バケットに配信されたログを Amazon ES に送信します。 Amazon ES で調査結果を分析、検索、集約します。 Kibana ダッシュボードを使用して結果を可視化します。 ここで手順を開始する前に、このAWS ブログ記事で概説しているように、マスターアカウントで GuardDuty を有効にします。マスターアカウントには、GuardDuty のすべての調査結果が集計されます。マスターアカウントは通常、セキュリティチームによって管理され、すべてのメンバーアカウントの結果が表示されます。 ステップ 1: AWS Lambda を使用して GuardDuty ログを収集し、Amazon […]

新しいAWS Database Ready Programを導入し、ソフトウェアベンダーが彼らのソフトウェアを現代化し、Amazon Auroraをサポートできるようにします。 顧客は、商用データベースのライセンス費用を掛けずに、Amazon Auroraの性能、可用性、およびオープンソースの簡潔性を活用するクラウドネイティブアプリケーションを求めています。 AWS Database Readyは、元々AWSデータベースサービスで実行されるアプリケーションを使用してクラウド移行を加速することを可能にするものです。

昨年、私たちは調整可能なボリュームと呼ばれる新しいAmazon EBS 機能を開始しました。Amazon EBSの調整可能なボリュームを使用すると、ボリュームの使用中に、EBSボリュームのサイズを増やしたり、IOPSまたはボリュームのタイプを変更したりすることができます。この変更は操作に影響を与えなく、行うことができます。 この3つのブログ記事のシリーズでは、Oracleデータベースでの調整可能なボリュームを使用するメリットを検討します。また、調整可能なボリュームを使用してデータベースストレージを増やし、データベースの可用性または性能に影響を与えなく、準備されたIOPSを変更する方法についても説明します。 1番目の記事では、データベースストレージマネジメント用のロジカルボリュームマネージャー（LVM）のないオペレーティングシステムファイルシステムを使用して、Oracleデータベースで調整可能なボリュームを使用する方法について説明します。2番目の記事では、データベースストレージマネジメントにLVMを使用するOracleデータベースについて説明します。3番目の記事では、Oracle自動ストレージマネージャー（Oracle ASM）を使用するOracleデータベースについて説明します。 Amazon EBSの調整可能なボリュームの概要 調整可能なボリュームを使用すると、EBSボリュームの使用中に、EBSボリュームのサイズを増やしたり、準備されたIOPSを調整したり、EBSボリュームのタイプを変更したりすることができます。データベースはオンラインのままで、変更が有効になっている間に使用可能となっています。 AWS マネジメントコンソールから、簡単なAPI呼び出しを使用して、またはAWSコマンドラインインターフェース（AWS CLI）を使用して、ボリュームの変更を要求することができます。変更されるEBSボリュームは一連の状態を経過します。ボリュームの変更を要求すると、ボリュームは変更 状態になり、次に最適化状態になり、最後に完了状態になります。 EBSのボリュームのサイズの変更は、完了するまでに通常だと数秒がかかり、ボリュームが最適化状態になってから有効となります。パフォーマンス（IOPS）の変更には数分から数時間かかることがあり、構造の変更が行われたかどうかで決まります。EBSボリュームは最適化 状態になっていますが、ボリュームのパフォーマンスはソースとターゲットの構成仕様の間にあります。 Amazon EC2におけるOracleデータベースストレージレイアウト Amazon EC2でOracleデータベースを実行する場合は、EBSボリュームをデータベースストレージに使用します。一般的に、高性能のデータベースワークロード用のio1ボリュームと、それよりもあまり要求のないその他のワークロード用のgp2ボリュームを選択します。IO1ボリュームは、遅延の影響を受けやすい取引ワークロード用に設計されており、ボリュームにあたり最大32,000 IOPSまで提供します。GP2ボリュームは、価格と性能のバランスが優れており、ベースラインIOPSは3 IOPS/GB、ボリュームにあたり最大10,000 IOPSを提供します。 Oracleデータベースの物理ストレージには、ディスクに格納されているファイルのセット（データ、一時的なファイル、再実行ファイル、制御ファイルなど）が含まれています。これらのファイルの作成および管理には、オペレーティング・システムのファイル・システム、LVM、またはOracle ASMを使用することができます。 単純なデータベースストレージ操作 このセクションでは、単一のEBSボリュームとオペレーティングシステムファイルシステム（LVMなし）をデータベースストレージに使用する単純なOracleデータベース用のAmazon EC2におけるストレージレイアウトについて簡単に説明します。次に、準備されたストレージを増やしたり、準備されたIOPSを変更したりすることなどといったOracleデータベースのストレージの変更が調整可能なボリュームの導入前にどのように行われたかについて説明します。私たちは、この変更に関連する問題点を説明します。最後に、調整可能なボリュームを例に、これらの問題点のいくつかを解決する方法をお教えします。 単純なデータベースのストレージレイアウト 単純なデータベースについて、データベースストレージ用に単一のEBSボリュームのみを使用する場合があります。データベースファイルを格納するには、データベースファイルを分割してファイルシステムを作成します。このシナリオでは、LVMを使用しません。次の図は、この単純なデータベースストレージレイアウトを示しています。 調整可能ボリュームではないストレージ操作 データベースストレージ用の単一のEBSボリューム（LVMなし）を使用してストレージを増やしたり、またはシステム用に準備されたIOPSを変更したりすることができます。これを行うには、現在のEBSボリュームのスナップショットから目的のサイズとIOPSで新しいEBSボリュームを作成し、EBSボリュームをスワップします。この操作を行うには、次の手順を実行します。この操作には、データベースを停止する時間が必要です。 データベースを停止し、EBSボリュームのスナップショットを作成します。 スナップショットから求めたサイズとIOPSで新しいEBSボリュームを作成します。 古いEBSボリュームをEC2インスタンスから切り離し、新しいEBSボリュームをEC2インスタンスに接続します ファイルシステムのサイズを変更し（EBSのボリュームサイズが変更されている場合）、データベースを起動します。 調整可能なボリュームによる保管作業 EBSボリュームを変更するには、AWS CLIからの変更 – ボリュームコマンドまたはAWS マネジメントコンソールからの変更 – ボリュームオプションを使用します。その場合は、新しいボリュームサイズとIOPSを指定します。ボリュームサイズを変更せずに準備されたIOPSのみ変更する場合は、オペレーティングシステムレベルで変更する必要はありません。EBSボリュームのサイズを変更する場合は、ボリュームの変更後にファイルシステムのサイズを変更する必要があります。 EBSボリュームのサイズまたはIOPSを変更すると、データは自動的に複数のバックエンドデバイスに分散され、ホットスポットが発生しないようにしたり、準備されたIOPSを取得するようにします。 例：LVMを使用せずに単純なデータベースのストレージを増やす このセクションでは、停止時間が無くても、オペレーティングシステムファイルシステムをストレージマネジメントに使用するOracleデータベース用に準備されたストレージを増やす方法を示します。このデモでは、Amazon Linuxの上で動作するOracle 12cデータベースを使用します。30-GiB EBSボリュームがインスタンスに接続され、Oracleデータベースストレージ用のファイルシステムが作成されます。このデモでは、停止時間がなく、30 GiBから60 GiBに準備されたストレージを増やします。 サイズ変更がデータベースの停止時間なしに実行されたことを示すため、evtestprocというデータベースストアドプロシージャを作成しました。このプロシージャは、レコードを10秒間隔でevtesttabというテーブルに挿入します。このプロシージャは、サイズ変更操作の実行中に行われます。レコードが10秒間隔でevtesttabテーブルに挿入されていることを確認して、データベースの停止時間なしにサイズ変更が完了したことを確認できます。 ステップ1：現在の設定を確認する AWSマネジメントコンソールから、EBSボリュームのサイズを確認します。現在、次のスクリーンショットが示すように30 […]

Amazon Relational Database Service (Amazon RDS) Performance Insights を使用すれば、パフォーマンスの問題の原因だけでなく、Amazon RDS データベース上のワークロードの性質を即座に把握できます。このブログ記事では、Amazon Aurora MySQL-Compatible Edition の Performance Insights ダッシュボードを手短に見て、パフォーマンスの問題を分析する方法を学びます。前回のブログ記事「Performance Insights で Amazon RDS データベースのワークロードを分析する」では、Performance Insights へのアクセスに関する基本的な事項と、Amazon Aurora PostgreSQL-Compatible Edition でそれを使用することについて取り上げました。 以下では、Performance Insights が、Aurora MySQL データベースで実行されている負荷が示されています。この例では、負荷グラフは待機でスライスされます。待機から、どのような作業が負荷の原因となっているか、そしてCPU、I/O 読み取り、ロック、安定したストレージへの書き込み、または他のデータベースリソースからの競合によってどれくらいの負荷がかかているかがわかります。Aurora MySQL は、MySQL の Performance Schema を使用してデータベースの待機を計測します。つまり、Performance Insights を最大限に活用したい Aurora MySQL ユーザーは、MySQL Performance Schema を有効にする必要があります。RDS パラメータグループで Performance Schema を有効または無効にしたことがない場合は、Performance Insights を有効にすると、自動的に […]

 AWS オンラインテックトークは、様々な技術レベルで幅広いトピックをカバーするライブでのオンラインプレゼンテーションです。 今月は、AWS のサービスとソリューションについて学びましょう。ご質問があれば、オンラインで専門家がお答えします。 今月の特集！ テックトークをチェック: Virtual Hands-On Workshop: Amazon Elasticsearch Service – Analyze Your CloudTrail Logs、AWS re:Invent: Know Before You Go、AWS Office Hours: Amazon GuardDuty Tips and Tricks いますぐ登録を！ 注意 – すべてのセッションは無料で、太平洋時間です。 今月のテックトーク: AR/VR 2018 年 11 月 13 日 | 午前 11:00 ～ 12:00 (太平洋時間) – How to Create a Chatbot Using Amazon […]

データレイクはあらゆる規模で構造化および非構造化データを格納するために使用できる集中リポジトリを提供します。データレイクには、未加工のデータセットと整理され、クエリ用に最適化されたデータセットの両方を格納できます。未加工のデータセットは本来の形式で、素早く取り込むことが可能で、事前定義されたスキーマに無理矢理押し込める必要がありません。データレイクを使用すると、未加工と整理されたデータセットの両方に異なるタイプの分析を実行できます。データレイクのストレージレイヤーに Amazon S3 を使用することで、バケットとオブジェクトレベルの両方を細かくコントロールできるようになります。レイクのデータセットのアクセスコントロールポリシーを定義するためにこれらを使用できます。 AWS Glue データカタログは、永続型のフルマネージドメタデータストアで、AWS のデータレイクに使用できます。Glue データカタログを使用することで、Apache Hive Metastore で実行するのと同じ方法で AWS クラウドでもメタデータの保存、注釈の付与、共有を実行できます。Glue データカタログはまた、Amazon Athena、Amazon EMR、Amazon Redshift Spectrum などと、シームレスで、細かな設定の不要な統合を実現できます。 AWS Glue を使用することで、ユーザー、ロールをベースにした、または、リソースレベルに適用した、カタログの異なる部分へのアクセスを制限するポリシーの作成も可能です。これらのポリシーを使って、どのユーザーがデータレイク内で種々のメタデータ定義にアクセスできるかを詳細にコントロールできます。 重要: S3 および AWS Glue データカタログのポリシーは、それぞれ、データとメタデータ定義のアクセス許可を定義します。言い換えれば、AWS Glue データカタログのポリシーは、メタデータへのアクセスを定義し、S3 ポリシーはコンテンツそのものへのアクセスを定義します。 GetDatabases、GetTables、CreateTable、およびその他の個人識別ベースのポリシー (IAM) を使用して、どのメタデータを操作できるようにするか制限できます。また、その操作で実行するデータカタログオブジェクトも制限できます。さらに、結果の呼び出しで戻されるカタログオブジェクトを制限できます。ここで言う Glue データカタログの「オブジェクト」とは、データベース、テーブル、ユーザー定義の関数、または Glue データカタログに格納された接続を指します。 データレイクの本番環境のデータベースとテーブルに読み取りアクセスが必要で、他にはリソースを開発するための追加的なアクセス権限があるユーザーがいるとします。また、未加工データのフィードとビジネスインテリジェンス、分析、機械学習などのアプリケーションで使用された整理済みのデータセットの両方を格納するデータレイクがあるとします。これらの構成を簡単に設定でき、AWS Glue データカタログのアクセスコントロールメカニズムを使用して、他のものも多数簡単に設定できるようになります。 注意: 以下の例では、AWS Glue データカタログでポリシーをセットアップする方法について解説します。関連付けられた S3 バケットやオブジェクトレベルのポリシーは設定しません。これは、Athena、EMR、AWS Glue データカタログと統合されるツールの使用時、メタデータが検出できないことを意味します。誰かが S3 オブジェクトに直接アクセスしようとしたときに、S3 ポリシーが強制されることが重要です。データカタログと S3 バケットまたはオブジェクトレベルのポリシーを一緒に使用する必要があります。 […]

AWS re:Invent 2018まで3週間を切った中で、同僚と私は、地球上で最高の教育イベントを生み出すためにこれまで以上に努力をしています！ 複数の主要点、2000以上のセッション、ブートキャンプ、チョークトーク、実践的なワークショップ、ラボ、そしてハッカソンから選択することで、あなたがここに到着したときよりもラスベガスの情報をより良く伝えられることを確信しています。 私にChallenge 今日、AWSの知識を新しい形で使用する機会についてお話したいと思います。今すぐ申し込み、Camp re：Invent Trivia Challenge（11月28日午後7時、ヴェネツィアシアター）に参加してください。AWSに関する質問に答えたり、楽しい時間を過ごしたり、限定版Camp re:InventやJeff Barrのピンを手にすることで、私と競争する機会があります。何を勉強したいのか、どのように準備するのかが分からないので、本当にすごく面白いことが起こります。 チャレンジしよう、おいしいもののために立ち寄ろう ちなみに、様々なイベントや特定のセッションに参加することで獲得できる60以上のAWSピンに加えて、パートナーとスポンサーからそれらを得ることができます。他のre:Invent参加者とピンを交換することもできます。これは、獲得できる、見つけられる、または取引できるピンのほんの一部です（非公式@reinventPartiesリスト経由）： また、私は新しくて可愛いステッカーをいくつか持っていきます： ラスベガスでお会いしましょう ラスベガスでファンやお友達と会うのを楽しみにしています。私は週に多くの課題を持っていますが、いつも立ち止まって挨拶する時間はあります。どうか恥ずかしがり屋にならないでください！ — Jeff;

本シリーズのパート 1 では、データレイクをサポートするデータパイプラインの構築方法について説明しました。そのために、Amazon Kinesis Data Streams、Kinesis Data Analytics、Kinesis Data Firehose、および AWS Lambda などの AWS の主なサービスを使用しました。パート 2 では、主要分析を使って実用的なデータを作成するサーバーレスデータレイクを作成することによってデータを処理し、可視化する方法について説明します。 サーバーレスデータレイクの作成と、AWS Glue、Amazon Athena、および Amazon QuickSight を使用したデータの調査 パート 1 で説明した通り、心拍数データは Kinesis Data Streams を使用して Amazon S3 バケットに保存できます。しかし、リポジトリにデータを保存するだけでは十分ではありません。分析のための有意義なデータを抽出できるように、リポジトリに関連する関連メタデータをカタログ化し、保存することができる必要もあります。 サーバーレスデータレイクには、完全マネージド型のデータカタログおよび ETL (抽出、変換、ロード) サービスである AWS Glue を使用できます。AWS Glue は、困難で時間のかかるデータ検出、変換、およびジョブスケジュールのタスクを簡素化し、自動化します。AWS Glue Data Catalog のデータを最適なパフォーマンスのためにパーティション分割して圧縮すると、S3 データへの直接クエリのために Amazon Athena を使用できます。その後、Amazon QuickSight を使用してデータを可視化できます。 以下の図は、このデモで作成されるデータレイクを表しています。 今現在、Amazon S3 […]

AWS Glue は、データのカタログ化、クリーニング、強化を行い、様々なデータストア間で確実に移動させる完全マネージド型 ETL (抽出、変換、ロード) サービスです。AWS Glue ETL ジョブは、AWS 環境の内外にある多種多様なデータソースとやり取りすることができます。ハイブリッド環境での最適な運用には、AWS Glue に追加のネットワーク、ファイアウォール、または DNS 設定が必要になる場合があります。 この記事では、一般的なデータレイクの取り込みパイプラインをシミュレートする、AWS Glue を使用したデータの変換と、オンプレミスデータストアから Amazon S3 へのデータの移動のためのソリューションについて説明します。AWS Glue は、Amazon S3 と、Amazon RDS、Amazon Redshift、または Amazon EC2　で実行されているデータベースなどの Virtual Private Cloud (VPC) に接続できます。詳細については、「データストアに接続を追加する」を参照してください。AWS Glue は、PostgreSQL、MySQL、Oracle、Microsoft SQL サーバー、および MariaDB などの各種オンプレミス JDBC データストアにも接続できます。

 スポーツ関連の軽度外傷性脳損傷 (mTBI) は、医学界、スポーツ界、そして子育てコミュニティの異なるグループの中で懸念を生じ続けています。アメリカでは、レクリエーションレベルで毎年約 160～380 万件の mTBI 事故が起こっており、そのほとんどが病院で治療を受けていません。(その他のリソースにある「The epidemiology and impact of traumatic brain injury: a brief overview」を参照してください。) 軽度外傷性脳損傷の医療および間接的な費用の推定額は、毎年 600 億 USD に上っています。 北アメリカの救急医療施設では、入院患者の外傷性脳損傷 (TBI) ケースに関するデータを収集していますが、スポーツ選手たちの中で起こった未報告の mTBI の件数について、意味のあるデータはありません。最近の研究では、スポーツ関連の mTBI について、多くの要因による極めて高い過小報告率が示されています。これらの要因には、チームスタッフが単に兆候や症状を認識できない、またはその影響を実際に目にしていないことが含まれます。(その他のリソースにある「A prospective study of physician-observed concussions during junior ice hockey: implications for incidence rates」を参照してください。) ホッケーやフットボールの選手の大部分は、大学の選手でもなければ、プロの選手でもありません。ユースホッケーの選手は 300 万人を超え、約 500 万人がフットボールに参加登録しています。(その他のリソースにある「Head Impact Exposure in Youth Football」を参照してください。) これらのレクリエーション選手たちには、脳震盪の認識、サイドラインでの外傷評価における訓練を受けた医療スタッフへの基本的なアクセスがありません。利用しやすい測定とスマートフォンベースの評価ツールは、頭部外傷の可能性の特定、評価、および競技復帰 (RTP) […]