Amazon Web Services ブログ

昨年開催された AWS re:Invent で AWS OpsWorks for Chef Automate を公開しました。これはユーザーが AWS マネージド型の独自の Chef Automate サーバーを利用できるようにするものです。そして、ユーザーからのフィードバックを元に構築した Puppet Enterprise を OpsWorks に追加しました。 Puppet Enterprise は、管理されている各ノードでデプロイした puppet-agent を介してプロビジョニング、設定、インスタンスの管理を自動化できるようにします。設定は 1 回定義することができ、自動ロールバックとドリフト検出で何千件ものノードに適用することができます。AWS OpsWorks for Puppet Enterprise は、既存の Puppet マニフェストでシームレスに連動させながら、独自の Puppet マスターを管理する必要を排除します。 OpsWorks for Puppet Enterprise は、ユーザーの代わりに Puppet マスターサーバーを管理し、インストール、アップグレード、バックアップといった運用タスクを行います。また、ノード登録を簡素化したり、ノードのブートストラップの便利なスターターキットも提供しています。詳細については次をご覧ください。 Managed Puppet Master の作成 OpsWorks で Puppet マスターを作成するのは簡単です。まず、OpsWorks コンソールの [Puppet] セクションにアクセスし [Create […]

今年初めにリリースした x1e.32xlarge インスタンスは、4 TB のメモリを持つ 4 つの AWS リージョンを対象に利用可能となりました。そのリリースから 2 か月後の現在、ユーザーはハイパフォーマンスリレーショナルと NoSQL データベース、メモリ内データベース、そして大量のメモリを活用できる他のエンタープライズアプリケーションに、このインスタンスを使用しています。 X1e のサイズを 5 つ追加 メモリ最適化 X1e シリーズにインスタンスサイズを 5 つ追加しました。ラインアップは次の通りです。 モデル vCPU メモリ (GiB) SSD ストレージ (GB) ネットワーキングパフォーマンス x1e.xlarge 4 122 120 最大 10 Gbps x1e.2xlarge 8 244 240 最大 10 Gbps x1e.4xlarge 16 488 480 最大 10 Gbps x1e.8xlarge 32 976 960 […]

※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 […]

Aravind Kodandaramaiah は AWS パートナープログラムのパートナーソリューションアーキテクトです。 はじめに AWS ワークロードを実行するお客様は Amazon DynamoDB と Amazon Aurora の両方を使用していることがよくあります。Amazon DynamoDB は、どのような規模でも、一貫した、数ミリ秒台にレイテンシーを抑える必要のあるアプリケーションに適した、高速で柔軟性の高い NoSQL データベースサービスです。データモデルの柔軟性が高く、パフォーマンスが信頼できるため、モバイル、ウェブ、ゲーム、広告、IoT、他の多くのアプリケーションに最適です。 Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、オープンソースデータベースのコスト効率性と簡素性を備えた、高性能の商用データベースの可用性とスピードをあわせもったエンジンです。Amazon Aurora は、MySQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。 DynamoDB と Aurora を連携させるために、カスタムウェブ解析エンジンを構築して、毎秒数百万のウェブクリックが DynamoDB に登録されるようにしたとします。Amazon DynamoDB はこの規模で動作し、データを高速に取り込むことができます。また、このクリックストリームデータを Amazon Aurora などのリレーショナルデータベース管理システム (RDBMS) にレプリケートする必要があるとします。さらに、ストアドプロシージャまたは関数内で SQL の機能を使用して、このデータに対してスライスアンドダイスや、さまざまな方法でのプロジェクションを行ったり、他のトランザクション目的で使用したりするとします。 DynamoDB から Aurora に効率的にデータをレプリケートするには、信頼性の高いスケーラブルなデータレプリケーション (ETL) プロセスを構築する必要があります。この記事では、AWS Lambda と Amazon […]

自律走行シリーズ 1 回目のブログでは、Donkey カーの構築と Amazon EC2 インスタンスでパイロットサーバーをデプロイしました。そして、2 回目のブログでは Donkey カーの運転を学び、Donkey カーが自律走行を学びました。今回のブログでは、Donkey カーから AWS にテレメトリをストリーミングするプロセスをご紹介します。スケーラブルで信頼性が高く、当社の接続済み自律走行車など様々な接続済みデバイスに対し多機能な一連のサービスを提供する AWS IoT を使用します。 1) AWS 自律走行車を構築し re:Invent の Robocar Rally でレースに参加 2) 自律走行車の構築 パート 2: 自律走行車の運転 3) 自律走行車の構築 パート 3: 自律走行車の接続 4) 近日中に公開予定 AWS IoT のセットアップ 自律走行車は運転中に絶え間なくテレメトリをストリーミングします。自律走行車が稼働していない場合は収集するテレメトリがないため、リソースを使用しないことで無駄を避けます。ワークロードに対応するため、アーキテクチャ全体の稼働においてはサーバーレステクノロジーに依存します。開始するには、まず AWS IoT を使用してフリートモニタリングサービスを設計します。同じ基本的なアーキテクチャを使用して、その数に制限なく自律走行車に使用できます。次の図はフリートモニタリングサービスのアーキテクチャを示しています。 同ソリューションのコンポーネントは、論理的な機能 (および AWS のサービス) 別に色分けされ、ソリューションの各コンポーネントが安全でスケーラブルであり、完全に使用量ベースであることが示されています。この種のオペレーションモデルは様々なビジネスモデルで役立ち、幅広いサイズの顧客にとっても便利です。週末に趣味で自律走行車をレースしてラップタイムを比較したり、自動車メーカーが独自の接続された車両プラットフォームを開発したい場合でも、AWS IoT は安全でスケーラブルな使用量ベースのコスト構造を提供しています。 このソリューションは緑の網掛け部分の Donkey カーから始めます。次にデータが IoT サービスを通過してピンクのセクションに移動します。このセクションは DynamoDB の短期間用データストレージです。その後、S3 […]

–この記事はAWS セキュリティ・アシュアランス本部の寄稿です– 2016年12月に AWS Artifact のサービスが開始され監査レポート等コンプライアンスに関する重要な情報を提供してきましたが、2017年11月より同サービスにおいて、日本のお客様に向けて「日本準拠法に関する AWS カスタマーアグリーメント変更契約」の手続きが可能な新機能の提供を開始しました。これにより、AWS Artifact を通じて日本準拠法に関する AWS カスタマーアグリーメント変更契約をリアルタイムに締結または終了することが可能となっています。 日本準拠法に関する AWS カスタマーアグリーメント変更契約とは、現在お客様がご利用中の AWS アカウントに適用されている、 AWS カスタマーアグリーメントの準拠法および管轄裁判所を変更する契約を指します。この契約を有効にすることで、 AWS カスタマーアグリーメントの準拠法を日本法に変更し、更に、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更することができます。 従来、AWSカスタマーアグリーメントの準拠法および管轄裁判所を変更する際に、その都度、書面で契約を締結して頂く必要がありましたが、AWSアカウントのマネジメントコンソールからお客様ご自身で受諾（有効に）することで、お客様の手間を省略することが可能となっています。 AWSでは今後も日本のお客様の声に耳を傾け、サービスの拡充に努めていきます。 【AWS Artifactの操作方法】 AWS Artifactを使用した日本準拠法に関するAWSカスタマーアグリーメントの変更方法、操作方法については下記のリンクから動画をご参照ください。より詳細なAWS Artifactの情報については以下のartifactのページをご参照ください。 https://aws.amazon.com/jp/artifact/   【留意事項】  日本準拠法に関する AWS カスタマーアグリーメントは、請求連絡先アドレスが日本国内にあるアカウントに対してのみ提供されるものです。 複数のアカウントをお持ちのお客様の場合、アカウント毎に有効にして頂く必要があります。 既に個別に書面でカスタマーアグリーメントの準拠法および裁判管轄を変更する契約を取り交わしているお客様については、再度締結いただく必要はございません。 その他の詳細については下記のページをご参照ください。 https://aws.amazon.com/jp/artifact/faq/   – AWS セキュリティ・アシュアランス本部    

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。第2回目では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明しました。このシリーズの最後の記事として、内部接続と外部接続の両方を必要とするSAPアプリケーションの接続パターンを説明します。外部ソースからの接続は管理されていてもよく(つまり、既知の外部の関係者を含む)、管理されていない(つまり、公開されていてもよい)場合もあります。両方のシナリオについて説明します。 内部および管理された外部接続 外部向けインターフェースに対する信頼された外部の関係者からの接続と、内部向けインターフェースに対するSAPと非SAPシステム間またはどちらかの間の接続が必要となる、SAP Process Orchestration(PO)とSAP Process Integration(PI)がこのシナリオの典型的な例です。内部向けインターフェースは簡単に管理できます。基本的には、ルートテーブル、ネットワークアクセスコントロールリスト(ACL)、およびセキュリティグループに適切なトラフィックを定義します。しかしながら、外部接続を安全に提供することには課題があります。そこで、信頼できる外部の関係者からのトラフィックの入口と出口に着目しましょう。典型的な選択肢が4つあります。 入口と出口の両方のための仮想プライベートネットワーク(VPN)接続 入口用のElastic Load Balancing、および出口用のネットワークアドレス変換(NAT)ゲートウェイ NATデバイス(NATインスタンスまたはNATゲートウェイ) リバースプロキシ VPN接続 (入口と出口) 信頼できる外部の関係者と専用の仮想接続を作成する場合は、VPCでVirtual Private Gateway(VGW)を使用するか、パブリックサブネット内にAWS Marketplaceで公開されているような独自のソフトウェアVPNサーバを使用することで、サイト間IPsec VPN接続を確立できます。 注釈   この記事のアーキテクチャ図では、簡単にするために単一のアベイラビリティゾーンで示しています。実際には、高可用性を実現するために、少なくとも2つのアベイラビリティゾーンにわたってソリューションを構成することをお勧めします。 図 1: 管理された外部接続のためのVPNコネクション Elastic Load Balancing (入口) / NATゲートウェイ (出口) Elastic Load Balancingには、次の3つのタイプがあります。 Classic Load Balancer Network Load Balancer Application Load Balancer […]

AWS コミュニティヒーロープログラムでは、世界中の腕の良い AWS デベロッパーによって行われている革新的な作業の一部を紹介しています。このようなヒーローは、クラウドの専門知識と、コミュニティ構築および教育に対する熱意を組み合わせて、ソーシャルメディアや実際に顔合わせができるイベントで時間と知識を共有しています。また、カンファレンスで積極的にコミュニティ型の方向性を促進しています。今年の re:Invent では、多くのヒーローが Monday Community Day トラックでお話しする予定です。 大変うれしいことに、今年の 11 月、AWS のクラウド革新者ネットワークに 4 名のヒーローを迎えます。それでは早速、AWS コミュニティの新しいヒーローをご紹介します。 Anh Ho Viet Thorsten Höger Becky Zhang Nilesh Vaghela Anh Ho Viet Anh Ho Viet は、AWS ベトナムのユーザーグループ の設立者でありながら、OSAM の共同設立者兼 CEO、ベトナムの AWS コンサルティングパートナー、AWS 認定ソリューションアーキテクトという肩書きを持つクラウド愛好家です。 OSAM で、Anh と彼の熱意あふれるチームは、SMB からエンタープライズに至るまで、多くの企業の AWS クラウドへの移行をサポートしてきました。AWS の移行やコンサルティング、アーキテクチャ、ソリューション設計など、そのサービス範囲は多岐にわたります。OSAM に対する Anh のビジョンは、クラウドサービスプロバイダーの範囲にとどまりません。同社は、完全な AWS エコシステムをベトナムに構築し、トレーニングやコラボレーションといった活動を通して、ベトナムの他の企業に AWS パートナーになる機会を与える取り組みを行っています。 2016 […]

  Knievel Co は、アマゾン ウェブ サービスのデータベースエンジニアです。 このブログ記事では、Oracle データベースを PostgreSQL に移行する方法の概要について説明します。データベース移行の2つの主要部分は、スキーマの変換とデータの複製です。）AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して､これら 2 つの部分に取り組む方法について説明します。 SCT と DMSについて説明する前に、予備的な手順を実行する必要があります｡これらは､すべての移行に役立つことが判明しています。移行を容易にする方法の 1 つは、移行の前に､通常更新フェーズと呼ばれるものを行うことです｡このフェーズでは、Oracle データベース内のオブジェクトのインベントリを作成し、いくつかの決定を下します。 最初に、不要になったオブジェクトを削除します｡オブジェクトの移行にかかる時間は誰も気にかけませんが､無駄にしないでください。また､不要になった履歴データを削除することもできます。一時的なテーブルや過去のメンテナンス時のテーブルのバックアップコピーなど、不要なデータを複製するために時間を無駄にすることはありません。次に、LOB、CLOB、LONG などに保存されているフラットファイルおよび長い文字列を Amazon S3 または Amazon Dynamo DB に移動します｡このプロセスではクライアントソフトウェアの変更が必要となりますが、データベースが簡素化されサイズが削減されることで、システム全体がより効率的になります。最後に、PL/SQL パッケージとプロシージャを移動します｡特にビジネスロジックを含むものをクライアントソフトウェアに戻してみます。これらのオブジェクトは、SCT が変換できない場合は手動で変更する必要があります。 次の手順は、異なるデータベースエンジン (この場合は Oracle から PostgreSQL へ) に移行するための手順です。別のプラットフォームに移動していない場合は、データベースを移動するためのより適切なネイティブツールやその他のテクニックがあります。 ターゲットデータベースでスキーマを作成します。 ターゲットデータベースの外部キーとセカンダリインデックスを削除し、トリガーを無効にします。 データを複製するためのDMSタスクを設定します (全ロードと変更データキャプチャ (CDC))。 全ロードフェーズが完了したらタスクを停止し、外部キーとセカンダリインデックスを再作成します。 DMS タスクを有効にします。 […]

この記事は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 […]