Amazon Web Services ブログ

AWS での安全でスマートなコネクテッドマシンの実行

 この記事は、Konecranes 社のプラットフォームアーキテクトである Henri Gort 氏と、同社のデータレイクソフトウェアエンジニアである Mehmet Yalcinkaya 氏によるゲスト投稿です。彼ら自身の言葉を借りると、「Konecranes は世界をリードする Lifting Businesses™ のグループで、製造およびプロセス業界、造船所、港湾、およびターミナルなどの幅広いお客様にサービスを提供しています。『Konecranes』という言葉には、マシンを意味するフィンランド語の『Kone』と『cranes』が含まれいますが、実際のところ、私たちは生産性を向上させるリフティングソリューションだけでなく、あらゆるメーカーのリフティング装置へのサービスも提供しています。当社は、50 か国に約 16,000 人の従業員を抱えています」とのことです。 この記事では、Konecranes 社が産業用マシンのインテリジェンスとセキュリティを向上させるために、マシンに取り付けられたセンサーからの数十億もの記録をどのように利用しているかが説明されています。 データレイクの作成 まず、私たちは当社のセンサーデータを SQL Server から AWS に移行させました。これは、バッチ ETL プロセスをオンザフライで実行しながら、Amazon S3 および Amazon DynamoDB に SQL からデータを効率的に移動させるためにサーバーレスの AWS Glue サービスを使用して、データレイクを作成することによって実現されました。ETL プロセスは複数のクレーンの履歴データの集合体を対象とし、それらを整合されたデータ構造に統合することで、DynamoDB でマシンの KPI を導くデータをマイニングし、運用のデータを検証しました。 DynamoDB は、運用データを保存するために最適なデータベースです。DynamoDB のスケーリングし、データトラフィックのスパイクに対応する能力と、全体的なパフォーマンスは、Microsoft SQL Server 上の以前のデータベースアーキテクチャをはるかにしのぎます。移行以来、当社のデータベース速度が向上し、データベースの管理コストが低減されました。 AWS Glue の選択 ETL プロセスのための AWS Glue の導入は、複数のメリットを提供してくれました。 […]

Read More

Neptune Streams を使用したグラフの変化の取り込み

 多くのアプリケーションは、Amazon Neptune データベースに保存された項目の変更を、その変更が発生した時点で取り込む機能を利用することができます。Amazon Neptune は、Neptune Streams をサポートするようになりました。これは、Neptune のフルマネージド機能で、グラフに対するすべての変更を、発生順に確実にログに記録し、HTTP REST API を介してこれらの変更を利用可能にします。Neptune Streams は現在、ラボモードで利用可能です。 このブログ投稿では、Neptune Streams 機能を見直し、Neptune が提供するポーリングフレームワークを使用して Neptune と Amazon ElastiCache for Redis データストアを統合するストリームベースのアプリケーションをプロビジョニングし、この同じポーリングフレームワークを使用して独自のストリームベースのグラフアプリケーションを構築する方法を説明します。 Neptune Streams の概要 Neptune Streams を使用して、次のことを行うことができます。 ソース Neptune データベースから別の Neptune データベースに変更をレプリケートする ソース Neptune データベースから、Amazon DynamoDB または Amazon Aurora などの別のデータベースに変更をレプリケートする ソース Neptune データベースの変更を Amazon S3 にアーカイブする Amazon Elasticsearch でソース Neptune データベースで変わるコンテンツをインデックス作成する […]

Read More

Amazon DynamoDB で機密データを保護するためのベストプラクティスの適用

 このシリーズの最初の記事であるAWS データストア内の機密データを保護するためのベストプラクティスでは、いくつかの一般的なセキュリティの概念と、AWS データストアに適用できる AWS セキュリティコントロールについて説明しました。これらを使用して、データに関わるセキュリティ体制をより強固にすることができます。2 番目の記事であるAmazon RDS で機密データを保護するためのベストプラクティスの適用では、こうした概念を Amazon RDS データベースで実装する方法を示しました。この 3 番目であり、最後の記事では、これらの概念を Amazon DynamoDB で実装する方法を示します。 データの分類とセキュリティゾーンモデリング 処理しているデータと処理に関する特定の要件を理解することは重要です。こうした要件は規制であったり、組織の一部として内部的に作成される場合があります。たとえば、この記事で後述するように、データのトークン化などの特殊なセキュリティコントロールの一部は必要ではないかもしれません。常にセキュリティの水準を引き上げようとする必要がありますが、十分に理解してリスクを管理するために適切なコントロールを提供していることも確認してください。 セキュリティゾーンを設計したら、この記事で後述するように、ネットワークアクセスコントロールリスト (ACL) を使用して実装します。この手順では、ネットワークゾーンを粗く定義し、セキュリティグループを使用してこれらのゾーン内でより具体的なマイクロセグメンテーションを許可します。 セキュリティゾーンモデリングを実装するときは、ネットワーク設計を慎重に検討します。CIDR 範囲のサイズによって、各サブネットが表現できる IP アドレスの数が決まります。サブネット内の増加 (より多い IP アドレス) とサブネット数の増加をサポートできるように、CIDR 範囲を設計します。Amazon VPC とオンプレミスのデータセンター間、または VPC 間に矛盾のない IP アドレススペースを確保するための要件とバランスを取ります。詳細については、AWS 単一 VPC の設計を参照してください。 ここで提供されている詳細な説明、およびデータ分類とセキュリティゾーンモデリングの背景にある概念については、AWS データストア内の機密データを保護するためのベストプラクティスを参照してください。 予防的コントロール 次の図はこのシリーズの最初の記事からのもので、防御の概念を詳しく説明しています。コントロールには、予防的コントロールと発見的コントロールの 2 つの主要なカテゴリーがあります。最初に予防的コントロールについて説明しましょう。 DDoS 保護 AWS Shield と連携することで、アプリケーションおよびデータベースを分散サービス拒否 (DDoS) 攻撃から保護することができます。すべての AWS のお客様は、追加料金なしで […]

Read More

Amazon S3 レプリケーションに関連するデータ転送コストをモニタリングする

 この記事では、コンプライアンス、災害復旧、データ主権などのユースケースについて、Amazon S3 レプリケーションのコストと使用の詳細をモニタリングする方法を確認します。 Amazon Simple Storage Service (Amazon S3) では、Cross-Region Replication (CRR) を使用して別の AWS リージョンの異なるバケットに、または Same-Region Replication (SRR) を使用して同じ AWS リージョン内部のバケット全体にデータを自動的かつ非同期に複製できます。SRR と CRR が連携して Amazon S3 レプリケーションを形成し、クロスアカウントレプリケーションなどのエンタープライズクラスのレプリケーション機能を提供し、偶発的な削除や Amazon S3 ストレージクラスへのレプリケーションを防ぎます。 CRR は、地理的に異なる場所にデータのコピーを保持することにより、コンプライアンス要件を満たし、レイテンシーを最小限に抑えるのに役立ちます。SRR は、開発者アカウントとテストアカウント間のライブレプリケーションを設定し、データの主権に関する法律を遵守するのに役立ちます。どちらの設定でも、Amazon S3 はソースバケット内のすべてのオブジェクトを宛先バケットに複製するか、オプションでオブジェクトのサブセットを複製します。CRR または SRR の両方で、プレフィックスとタグを使用して、複製可能なデータを制御できます。 大きなプロジェクトまたは特定のユースケース (コンプライアンス、災害復旧など) の一部として Amazon S3 レプリケーションに固有のコストと使用状況をモニタリングする方法に課題が生じます。 ユーザーは AWS のコストと使用状況レポートを使用して、アカウントおよびその AWS Identity and Access Management (IAM) ユーザーが使用する各サービスカテゴリーの […]

Read More

AWS ブログの 15 年間

私(Jeff Barr: AWSのチーフエバンジェリスト)がこのブログに初めて投稿したのは(Welcome)、ちょうど 15 年前の今日のことになります。そのとき記した紹介の言葉のために、私のキャリアがこれほど新しくて常に変化する世界に入り込むことになるとは全く考えていなかったと言っても、今なら大丈夫でしょう。それから、このブログがどのように存在することになったかについての物語、私が気に入っている投稿のいくつか、執筆してブログに投稿するために実際に行っていることについてお話しするにもよい頃合いに思えます。 始まりのその前 1999 年前後のこと、私は Microsoft の Visual Basic チームの一員でした。XML が産声を上げたばかりで、Dave Winer が RSS について話し始めた頃です。VB6、XML、そして RSS が出会う交差点は私の好奇心を刺激し、私は片手間のプロジェクトとして Headline Viewer という小さなアプリを作り上げました。それをダウンロードできるようにしておいたところ、みんなはそれを気に入り、コンテンツの所有者は自分の RSS を含めてくれるよう私のところに送ってくるようになりました。フィードのリストは独り歩きを始め、みんなはアプリを欲しがると同じほどリストも欲しがりました。私もまた、サーバーのメルトダウンのため初期の自分の実体とでも言うべきものを失った後、その頃について記す 3 番目の個人ブログを始めました。 Aaron Swartz や他のみんなの激励により、私は Headline Viewer に手をかけるのをやめて、2001 年の末頃、フィードを集め、整理し、共有する Syndic8 立ち上げました。余暇を使って約 90,000 行の PHP コードを書きました。50 以上のテーブルを含む、非常に複雑な MySQL サーバーを中心としたものです。私はデータベースのホスティング、スケーリング、セキュリティ、そして管理について学びました。このサイトには、非常に広い範囲のクエリと更新操作をサポートする、XML-RPC ウェブサービスインターフェイスがありました。フィードのコレクションは最初の二、三年のうちに、ほぼ 250,000 のフィードを含むまでに成長しました。 そのときには気づいていなかったのですが、私の初期の XML、RSS、ブログ、ウェブサービスに関する経験は、やがてアマゾンに就職を申し込む時には、私を目立たせるほどのスキルとなっていました。ときには、私たちの趣味や個人的な関心が、ついにはキャリアを変えさせるほどの資産や特殊能力となることもあるのです。 E コマースとウェブサービス このようなことと並行して、私は 2000 年に Microsoft を退職し、当時は新しかったウェブサービスのコンサルティングを始めました。その当時、使われていたほとんどのウェブサービスは、キュートなデモ、株価情報、天気予報、通貨の変換以外の何者でもありませんでした。技術者なら、インターネットを行き交っていた関数コールを見て驚嘆したでしょうが、投資家は肩をすくめて通り過ぎるだけだったでしょう。 […]

Read More

Amazon QuickSight アクションでダッシュボードの対話性を強化する

Amazon QuickSight は、QuickSight アクションを通じて強化されたダッシュボードの対話機能を提供するようになりました。QuickSight アクションは、ダッシュボードでの単一のポイントアンドクリック操作を通じて高度なフィルタリング機能を提供します。アクションによって、ダッシュボード内のビジュアルをリンクして、あるビジュアル上の次元ポイントを選択すると、ダッシュボード内の他のビジュアル上の選択したポイントに関する詳細な洞察が得られるようにできます。したがって、概要から始めて、すべて同じダッシュボードシート内でビジネスメトリクスの詳細を掘り下げることができます。ダッシュボード内のどのビジュアルがインタラクティブであるか、これらのビジュアル間での相互作用を定義できます。この記事の執筆時点で、QuickSight アクションでは、フィルターアクションと URL アクションの 2 つの主要な対話機能を定義できます。Amazon QuickSight 内の URL アクションは新しいものではありませんが、URL アクションを作成するためのエントリポイントがアクションに統合されました。 QuickSight アクションは、少なくとも 1 つのディメンションを保持するサポート対象チャートに適用できます。この記事では、アクションの開始、ダッシュボードでのさまざまなアクションの設定、および設定されたアクションごとにさまざまな形式の対話機能を有効にする例を示します。 この記事では、次のデータセットを使用します。 B2B Sales このデータセットは、2016 年と 2017 年の架空の会社 ABCDO の注文詳細を保持しています。構築するダッシュボードは、業界、セグメント、地域別の販売指標を主要なディメンションとしてレポートし、購入された各注文のきめ細かい詳細も提供します。 Product Availability このデータセットは、ID ごとにすべての製品の利用可能な数量を保持しています。 前提条件 Amazon QuickSight ダッシュボードにアクションを実装する前に、ダッシュボードを作成および公開する方法を確認してください。 QuickSight アクションの使用を開始する このスクリーンショットは、上記の 2 つのデータセットから作成されたダッシュボードです。1 行目にカテゴリ、業種、地域ごとの売上。2 行目には四半期ごとの分野売上、分野ごとの業種売上。3 行目には総利益、売上、割引、販売数量。4 行目には注文詳細のピボット、5 行目には配送詳細のピボットを示しています。 始める前に、以下の用語に注意してください。 ソースビジュアル – アクションが作成されるビジュアルです。ソースビジュアル上のポイントを選択すると、アクションがトリガーされ、選択したディメンション値がフィルターとしてターゲットビジュアルに渡されます。 ターゲットビジュアル – ソースビジュアルで選択したディメンション値によってフィルタリングされるビジュアルです。 アクティベーション – […]

Read More

新機能 – CloudFormation スタックへの既存リソースのインポート

AWS CloudFormation を使うと、インフラストラクチャ全体を、テキストによりモデリングできます。この方法により、インフラストラクチャをコードのように扱うことが可能になり、ソフトウェアのバージョン管理やアーキテクチャ上の変更をデプロイ前にチームでレビューするなど、ソフトウェア開発のベストプラクティスを適用できるようになります。 初期段階でコンソールや AWS Command Line Interface (CLI) から作成された AWS リソースは、CloudFormation での管理が必要となる場合があります。たとえば、お客様 (あるいは他のチーム) で、 IAM ロール、仮想プライベートクラウド、または RDS データベースなどを移行の初期段階で作成し、その後、それらを同じスタックに組み入れ最終的なアプリケーションの形に仕上げるための作業時間を割いているとします。こういった場合、CloudFormation を使いリソースをゼロから再作成して、オリジナルのリソースから設定やデータを移行することも多くなります。 お客様によるこれらの手順を簡単にするため、 今回、CloudFormation スタックに既存のリソースをインポートすることが可能になりました。 リソース自体を削除せずに、スタックから除外することは、これまでも DeletionPolicy を Retain に設定することで可能でした。ここに、新なインポート機能も加わることで、利用範囲がさらに広がります。例として、現状では次のことが可能です。 既存リソースをインポートしながら新規のスタックを作成する。 すでに作成済みのスタックに既存リソースをインポートする。 スタック間でリソースの移行をする。 検出されたドリフトを修復する。 親スタックから子スタックを削除した後、別の親からインポートし直すことで、 ネストされたスタックのリファクタリングを行う。 CloudFormation スタックに既存リソースをインポートするには、以下のことが必要です。 インポートするリソースと (既存の) スタックに既に組み込まれているリソースを含む、スタック全体を記述したテンプレート。 インポートする各リソースのテンプレートには、 DeletionPolicy 属性が必要です。これにより、オペレーションの巻き戻しが安全かつ簡単に行えるようになります。 各ターゲットリソース固有の識別子。例としては、インポートをしたい Amazon DynamoDB テーブル、もしくは Amazon Simple Storage Service (S3) バケットの名前などが挙げられます。 リソースのインポート処理中、CloudFormation では次のことをチェックします。 インポートされるリソースが、同じリージョンにある別のスタックに属していないか (IAM ロールなどグローバルなリソースの場合ご注意ください) […]

Read More

[AWS Black Belt Online Seminar] AWS認定にチャレンジしよう – まずはクラウドプラクティショナーから 資料及び QA 公開

先日 (2019/11/07) 開催しました AWS Black Belt Online Seminar「 AWS認定にチャレンジしよう – まずはクラウドプラクティショナーから 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20191106 AWS Black Belt Online Seminar AWS認定にチャレンジしょう – まずはクラウドプラクティショナーから from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. 試験の予約画面で、「このサイトのご利用を続けるには、人口統計学情報を更新/確認してください」が表示されますが、これはブラウザーの設定の問題でしょうか? A. ログイン後にこのメッセージが表示された場合は、「人口統計」のリンクをクリックして、プロファイルのアップデートをお願いいたします。 Q. 会社が変わって、APNパートナーから一般ユーザーになったため、メールアドレス等が変更になっているのですが、問い合わせ先や変更手順に関してご教授いただけますか? A. こちらの「AWS クラウドに関するお問い合わせ」ページより、「AWS トレーニング・認定試験に関するお問い合わせ」内の「AWS の認定試験に関するご質問、お問い合わせ」を選択の上、ご連絡ください。 Q. テストは英語になりますでしょうか。日本語での対応はしておりますでしょうか。 A. 日本語、中国語 (簡体字)、英語、韓国語に対応しています。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。   […]

Read More

【開催報告】第10回 AWS Data Lake ハンズオンセミナー

こんにちは。PSA(パートナーソリューションアーキテクト) の大林です。 11月13日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。去年から行ってきた恒例のワークショップで第10回目となります。去年から引き続き盛況で、今回も80名以上のお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスである Amazon S3 を中心とした Data Lake について解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、Amazon Athena や Amazon Redshift の各 AWS サービスを駆使して実際にラムダアーキテクチャを構築することがゴールです。とはいえ全てを構築するのはボリュームが大きいため、スピードレイヤー or バッチレイヤー or 全部入りでコース分けて取り組めるようハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回は、サポートするソリューションアーキテクト5名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか? 「AWS Data Lake ハンズオンセミナー」は、来年も継続開催予定です。皆様のご参加お待ちしております。

Read More

Amazon CloudWatch を使用したクロスアカウントクロスリージョンダッシュボード

 AWS クラウドをデプロイするベストプラクティスには、複数のアカウントや複数のリージョンを使用することが含まれます。複数のアカウントは、リソースを分離し、問題の影響を軽減するセキュリティと請求の境界を提供します。複数のリージョンにより、高度な分離、エンドユーザーの低レイテンシー、およびアプリケーションのデータ復元力が保証されます。これらのベストプラクティスには、複雑な問題のモニタリングとトラブルシューティングが伴います。 集中運用チーム、DevOps エンジニア、およびサービス所有者は、複数のリージョンおよび多くのアカウントで実行されているアプリケーションを監視、トラブルシューティング、および分析する必要があります。アラームを受信すると、オンコールエンジニアはダッシュボードにログインして問題を診断する必要があり、他のアカウントにログインして複数のアプリケーションコンポーネントまたは依存関係の追加のダッシュボードを表示する必要があります。サービス所有者は、サービスの可用性に影響を与える可能性のあるアプリケーションリソース、共有リソース、またはアプリケーション間の依存関係を可視化する必要があります。複数のアカウントおよび/または複数のリージョンを使用すると、根本原因の分析のためにコンポーネントを相互に関連付けるのが難しくなり、解決までの時間が長くなります。 本日発表された Amazon CloudWatch クロスアカウントクロスリージョンダッシュボードにより、お客様は高レベルの運用ダッシュボードを作成し、ワンクリックでさまざまなアカウントの特定のダッシュボードへのドリルダウンを利用できます。その際、異なるアカウントへのログインとログアウト、またはリージョンの切り替えを行う必要はありません。アカウントおよびリージョン全体のパフォーマンスおよび運用データを可視化、集計、および要約する機能は、摩擦を軽減し、解決までの時間を短縮するのに役立ちます。クロスアカウントクロスリージョンは、たとえば他のアカウントやリージョンのアラーム/リソース/メトリックのみを表示したい場合、ダッシュボードを構築せずにナビゲーションのみに使用することもできます。 Amazon CloudWatch クロスアカウントクロスリージョンダッシュボードアカウントのセットアップ クロスアカウントクロスリージョンダッシュボードの使用は簡単で、必要に応じて AWS Organizations と統合することもできます。Organizations を使用して複数の AWS アカウントを制御および管理することにより、この記事でこれから紹介するとおり、ログインせずに、CloudWatch コンソールを使用して組織内のどのアカウントの titletitleAmazon CloudWatch ダッシュボード、メトリクス、アラーム間でも移動できます。もちろん、単一のアカウントに対してクロスリージョンダッシュボードをセットアップすることもできます。この記事では、Organizations との統合を利用します。 このブログ記事の助けになるように、Organizations コンソールを使用して組織を作成し、他のいくつかのアカウントを参加させました。前述のように、Organizations を使用すると、後でダッシュボードを設定するときにアカウントを簡単に選択できます。また、Organizations を使用せずにカスタムアカウントセレクターを事前入力することもできます。これにより、ダッシュボードを作成する際、アカウントを覚えたり、必要なときにアカウント ID を手動で入力したりする必要がなくなります。組織のセットアップ方法の詳細については、「AWS Organizations ユーザーガイド」を参照してください。組織のセットアップが完了したら、アカウントの設定を開始する準備が整いました。 私の最初のタスクは、ダッシュボードを作成するアカウントを識別して設定することです。これが私のモニタリングアカウントです (そして、複数持つことができます)。次に、モニタリングするアカウント (Organizations のメンバーアカウントと呼ばれる) を識別する必要があります。これらのアカウントは、モニタリングアカウントとデータを共有するように設定します。このモニタリングアカウントには、CloudWatch が各メンバーアカウントでロールを引き受けることを許可するための Service Linked Role (SLR) が必要です。クロスアカウントのクロスリージョンオプションを有効にすると、コンソールはこのロールを自動的に作成します。各メンバーアカウントを設定するには、アカウント内からモニタリングアカウントとのデータ共有を有効にする必要があります。 モニタリングアカウントから始めて、CloudWatch コンソールホームから、左側のナビゲーションパネルで [Settings] を選択します。Cross-Account Cross-Region がページの上部に表示されているので、[Configure] をクリックして開始します。 これにより、データ共有を有効にするためにメンバーアカウントでも使用する設定画面が表示されます。今のところ、モニタリングアカウントで [Edit] オプションをクリックして、クロスアカウントのクロスリージョンオプションを表示します。 モニタリングアカウントの最後のステップは、AWS Organization […]

Read More