Amazon Web Services ブログ

Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法

同僚のMadhuri Periが素晴らしい記事を書いてくれました。AutoScalingグループのクラスタをスケールダウンする際にインスタンスからタスクを事前に削除するために、コンテナ インスタンス ドレイニングを利用する方法です。 —– Amazon ECSクラスタでは、クラスタからインスタンスを削除する必要があるタイミングというのがいくつかあります。例えば、システムを更新するとき、Dockerデーモンを更新するとき、あるいはクラスタのサイズをスケールダウンするときなどです。コンテナ インスタンス ドレイニング機能によって、クラスタ上のタスクに影響を与えることなく、コンテナインスタンスを削除することができます。この機能により、コンテナインスタンスがDRAINING状態である間はそのインスタンスに対して新しいタスクの配置がスケジュールされないようになり、利用可能なリソースがあればサービスがタスクをクラスタ上の他のコンテナインスタンスに移動してくれ、インスタンスを削除する前にタスクの移動が成功したことを待機できるようになります。 コンテナインスタンスの状態は、手動でDRAININGに変更することが可能です。しかしこの記事では、これらのプロセスを自動化するためにAutoScalingグループとAWS Lambdaを利用してコンテナ インスタンス ドレイニングを行う方法を説明します。 Amazon ECS オーバービュー Amazon ECSはコンテナ管理サービスです。クラスタやEC2インスタンスの論理グループ上でDockerコンテナの実行、停止、そして管理を容易にしてくれます。ECSを使ってタスクを実行するとき、タスクはクラスタに配置されます。Amazon ECSは指定されたレジストリからコンテナイメージをダウンロードし、そしてそのイメージをクラスタ内のコンテナインスタンス上で実行します。 コンテナ インスタンス ドレイニングの状態を扱う AutoScalingグループはライフサイクルフックをサポートしています。ライフサイクルフックは、インスタンスの起動や削除の前に独自の処理を完了するために呼び出されます。今回の例では、ライフサイクルフックは、2つの処理を実行するLambdaファンクションを呼び出します。 ECSコンテナインスタンスの状態をDRAININGに変更します。 コンテナインスタンス上にタスクが1つも残っていないことを確認します。もしドレイニング中のタスクがまだ存在する場合は、Lambdaファンクションを再度呼び出すためにSNSにメッセージを送信します。 コンテナインスタンス上で実行中のタスクがなくなるか、あるいはライフサイクルフックのハートビートタイムアウト(サンプルのCloudFormationテンプレートではTTL15分に設定)に達するか、どちらかの状態になるまでLambdaによってステップ2が繰り返されます。その後、制御はオートスケーリングのライフサイクルフックに戻され、そのインスタンスは削除されます。このプロセスを次の図に示します。 試してみましょう! この記事で説明した一連のリソースをセットアップするためにCloudFormationテンプレートを使用します。このCloudFormationテンプレートを使用するには、あなたのアカウントのS3バケットにLambdaデプロイメントパッケージをアップロードする必要があります。このテンプレートは次のリソースを作成します。 VPCと関連するネットワーク要素(サブネット、セキュリティグループ、ルートテーブルなど。) ECSクラスタ、ECSサービス、そしてサンプルのECSタスク定義 削除のライフサイクルフックと2つのEC2インスタンスが設定されたAutoScalingグループ Lambdaファンクション SNSトピック Lambdaを実行するために必要なIAMロール CloudFormationスタックを作成し、インスタンスの終了イベントをトリガーすることによってどのようにこのスタックが機能するのか見ていきます。 Amazon EC2のコンソールにおいて、AutoScalingグループを選択し、CloudFormationによって作成されたAutoScalingグループの名前(CloudFormationテンプレートのリソースのセクションから)を選択します。 操作、編集を選択し、インスタンスの希望の数を “1” に減らすようにサービスを更新します。これによって、2つのインスタンスのどちらか一方で終了プロセスが開始されます。 AutoScalingグループのインスタンスタブを選択します。1つのインスタンスのライフサイクルの状態が “Terminating:Wait” という値を示すはずです。 この状態になると、ライフサイクルフックが発火してSNSにメッセージが送信されます。そして、SNSメッセージトリガーに反応してLambdaファンクションが実行されます。 Lambdaファンクションによって、ECSコンテナインスタンスの状態がDRAININGに変更されます。その後、ECSサービススケジューラによってこのインスタンス上のタスクは停止され、利用可能なインスタンス上でタスクが起動されます。 ECSのコンソールに移動すれば、コンテナインスタンスの状態がDRAININGになっていることを確認できます。 タスクが全て完了すると、AutoScalingグループのアクティビティ履歴でEC2インスタンスの削除を確認できます。 どのように動作しているか 少しLambdaファンクションの内部的な動作を見てみましょう。ファンクションはまず最初に、受け取ったイベントのLifecycleTransitionの値が autoscaling:EC2_INSTANCE_TERMINATING にマッチするかをチェックします。 # もし受け取ったイベントがインスタンス終了中ならば・・・ if ‘LifecycleTransition’ […]

Read More

Amazon クラウドディレクトリ – 階層データ用のクラウドネイティブなディレクトリ

当社のお客様は、これまでディレクトリ (一般的には Active Directory ライトウェイトディレクトリサービスや LDAP ベース) を使って階層別に整理されたデータを管理してきました。しばしば階層として表されるものには、デバイスレジストリ、コースカタログ、ネットワーク設定、ユーザーディレクトリがあり、同じコレクション内のオブジェクト間で複数のタイプの関係を持つ場合もあります。たとえば、ユーザーディレクトリは物理的な場所 (国、都道府県、市町村、建物、フロアー、オフィス) に基づいて 1 つの階層を持ち、プロジェクトや請求コードに基づいて 2 つ目の階層を持ち、管理チェーンに基づいて 3 つ目の階層を持つ場合があります。ただし、従来のディレクトリ技術では、単一のディレクトリ内で複数の関係の使用がサポートされません。これを行う必要がある場合は、追加のディレクトリを作成して管理する必要があります。もう 1 つの重要な課題として、スケールがあります。階層の基本的なオペレーションとして、特定のオブジェクトの親オブジェクトまたは子オブジェクトを見つける必要があります。その階層を使用して大規模なネストした情報のコレクションを表すことができる場合、この基本的なオペレーションは、オブジェクトの数やネストの深さにかかわらず、可能な限り効率的でなければなりません。従来のディレクトリはスケールが困難で、複数の階層を表すために 2 つ以上のディレクトリを使用する場合、苦労が増すばかりです。 新しい Amazon クラウドディレクトリ 本日、Amazon Cloud Directoryをリリースします。このサービスは、上記で説明したような、厳密に型指定された大量の階層データの保存に焦点を絞ったものです。コスト効率を維持しながら数億個のオブジェクトにスケールする機能により、 はあらゆる種類のクラウドおよびモバイルアプリケーションに最適です。 は、 や を含む、他の AWS のサービスで既に利用されている構成要素です。これは AWS 内で非常に重要な役割を果たすため、スケーラビリティ、高可用性、およびセキュリティを考慮して設計されました (データは保管時および伝送中に暗号化されます)。 はマネージド型サービスであるため、ソフトウェアのインストールやパッチ適用、サーバーの管理、ストレージまたはコンピューティングインフラストラクチャのスケーリングについて考える必要がありません。スキーマを定義し、ディレクトリを作成してから、クラウドディレクトリ API を呼び出してディレクトリへの入力を行うだけです。この API は速度とスケールを実現し、効率的なバッチベースの読み書き関数を持つよう設計されています。ディレクトリの長期間使用できる特性に、運用期間中にサポートする必要があるユースケースのスケールや多様性を組み合わせることで、別の課題が明らかになります。経験によれば、静的スキーマはスケールと新しいユースケースによって生じる変更に対応する柔軟性に欠けることがわかっています。この課題に対応し、ディレクトリを将来にも十分対応できるようにするため、 は変更の余地を明確に残したモデルという概念に基づいて作成されています。新しいファセットを追加して、既存のスキーマを拡張します。これは既存のデータをそのまま残す安全なオペレーションであり、既存のアプリケーションは引き続き予期どおり動作します。スキーマとファセットを組み合わせることにより、同じディレクトリ内で複数の階層を表すことができます。たとえば、最初の階層では組織図をミラーリングするとします。後で、各従業員の追加のプロパティ (2 番目の電話番号またはソーシャルネットワークのハンドルなど) を追跡するために別のファセットを追加できます。その後、同じデータ内で地理指向の階層を作成できます (国、都道府県、建物、フロアー、オフィス、従業員など)。説明したように、AWS の他の部分では既に を使用しています。Cognito ユーザープール は を使用してアプリケーション固有のユーザーディレクトリを提供しており、ユーザーのサインアップ、サインイン、および多要素認証をサポートしています。Cognito ユーザープールでは、数億人のユーザーをサポートするようスケールするフルマネージ型のサービスにより、モバイルおよびウェブアプリに簡単かつ安全にサインアップおよびサインイン機能を追加できます。同様に、 は を使用して関連する AWS アカウントグループの作成をサポートし、複数の階層を十分に活用して幅広いポリシーを適用します。詳しい内容を見る前に、 […]

Read More

AWS ホットスタートアップ – 2017 年 1 月

新年の始まりにあたり、再び Tina Barr が優れた多くのスタートアップ企業をさらに紹介します。ぜひご覧ください。 -Ana 本年も引き続き、AWS を利用しているホットなスタートアップ企業を紹介していきます。本日は、3 つの新しいスタートアップ企業を紹介します。 ClassDojo – 教師、児童生徒、親をクラスへとつなぎます。 Nubank – 銀行取引の概念を変える金融サービスのスタートアップ企業。 Ravelin – 機械学習モデルの上に構築された不正検出会社。 昨年の主なスタートアップ企業の紹介をまだお読みになっていない場合は、「1 年を振り返る」をぜひご覧ください。 ClassDojo (サンフランシスコ) 2011 年に Liam Don 氏と Sam Chaudhary 氏によって開始された ClassDojo は、クラス向けの通信プラットフォームです。教師、親、児童生徒は 1 日を通じて、写真、ビデオ、メッセージングを通じた重要な時間を共有するための場所としてこれを使用できます。今日、多くのクラスが万人向けのモデルとして運営されている中、ClassDojo の創設者は教育システムを改善し、世界中の 7 億人の初等教育の対象児童に、最善のコンテンツやサービスを受けさせたいと考えました。Sam と Liam が、クラスにとって何が最も役立つかを教師に質問したところ、多くの教師は、思いやりや寛容さのあるコミュニティが必要と答えました。つまり、クラスにかかわっている全員につながることができるコミュニティです。ClassDojo では、教師は児童生徒やその親と協力して独自のクラス文化を創造することができます。ClassDojo は 5 年で米国およびその他 180 か国の幼稚園から中学校までの 90% に拡大し、そのコンテンツは 35 か国語以上に翻訳されました。最近、ハーバード大学およびスタンフォード大学と共同作成された「Empathy and Growth Mindset」のビデオシリーズにより、さらに多くのクラスに拡大しました。これらのビデオは、米国の 14 歳以下の子どもの 3 […]

Read More

AWS IPv6 の更新 – 15 のリージョンおよび複数の AWS のサービスにまたがるグローバルサポート

過去数年間に、IPv6 のサポートを AWS の多くの異なる部分に追加してきました。最初は 、、、、、、および S3 Transfer Acceleration から開始し、最終的には先月発表した Virtual Private Cloud の EC2 インスタンスに対する IPv6 のサポート (当初は リージョンで利用開始) にまで拡大されました。本日は、VPC の EC2 インスタンスに対する IPv6 のサポートが、合計 15 のリージョンで利用でき、これらのリージョンのうち 9 つで、IPv6 に対する Application Load Balancer のサポートが利用できるようになったことをお知らせします。IPv6 アドレスを使用できるアプリケーションを構築およびデプロイして、サーバー、オブジェクトストレージ、ロードバランサー、およびコンテンツ配信サービスと通信できます。Apple および他のベンダーからの IPv6 サポートの最新のガイドラインに従い、モバイルアプリケーションは、AWS と通信するときに IPv6 アドレスを使用できるようになりました。 IPv6 が 15 リージョンで利用可能に 新しい VPC および既存の VPC の EC2 インスタンスに対する IPv6 のサポートが、、、、、、、、、、、、、、、および リージョンで利用可能になり、今すぐ使用を開始できます。新しい […]

Read More

AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント

同僚のJohn PignataがAmazon ECSに対する継続的デプロイメントパイプライン作成方法について素晴らしいブログを書いてくれました。 — 今日のビジネス環境では、新しいソフトウェアの反復を高速で提供することは競合に対するアドバンテージになります。企業がイノベーションを顧客に提供するスピード、変化する市場に適応するスピードは、ますます成功と失敗の違いを生む重要な要素になっています。 AWSは、企業がアプリケーションやサービスを高速に提供する組織の能力を向上させるDevOpsと呼ばれる文化哲学、実践、ツールの組み合わせを企業が採用できるように設計された一連の柔軟なサービスを提供します。 このポストでは、継続的デプロイメントと呼ばれるデプロイの実行方法について説明し、AWS CodePipeline、 AWS CodeBuild、および AWS CloudFormationを使用してAmazon ECS上のDockerコンテナとして提供されるアプリケーションの自動デプロイメントパイプラインを実装するためのリファレンスアーキテクチャの概要を説明します。 継続的デプロイメントとは? 俊敏性は、ITリソースのトラディショナルな提供方法に比べてクラウドコンピューティングが持つ重要な利点としてよく引用されています。他の部門が新しいサーバーをプロビジョニングするのに数週間か数ヶ月待つ代わりに、開発者はシングルクリックやAPIコールで新しいインスタンスを作成することができ、数分で使用開始することができます。この新たな速度と自律性は、開発者が新しい製品や機能を試し、できるだけ早く顧客に提供するこを可能にします。 製品の市場投入期間を短縮し、コードの品質を向上させ、より信頼性の高い製品やサービスのリリースを実現するために、開発チームはクラウド上でDevOpsの実践を採用しています。 継続的デプロイは、新しいソフトウェアリビジョンが自動的にビルドされ、テストされ、パッケージ化され、本番環境にリリースされる、DevOpsの実践です。 継続的デプロイにより、開発者は完全に自動化されたソフトウェアリリースプロセスを通じて機能や修正を出荷できます。開発者は、数週間や数ヶ月にわたる大規模なリリースをバッチ処理し、手動で展開する代わりに、新しいソフトウェアリビジョンが準備され次第、自動化されたプロセスを使用してアプリケーションのバージョンを1日に何回も配信することができます。クラウドコンピューティングがリソースの調達期間を短縮するのと同様に、継続的デプロイは新しいソフトウェアのリリースサイクルを数週間~数ヶ月から数分間に短縮します。 このスピードと敏捷性を活用することには、次のような多くの利点があります。 新機能やバグ修正を迅速にすることができる :  ソースコードリポジトリに置いてあるコードは、ビジネス価値をもたらしたり、顧客に利益をもたらすものではありません。新しいソフトウェアリビジョンをできるだけ早くリリースすることで、顧客はより迅速に利益を享受できるようになり、チームはより集中的なフィードバックを得ることができます。 変更セットが小さくなる : 大きな変更セットは、問題、バグ、およびその他の退化の根本原因を突き止める際に問題を引き起こします。より小さな変更セットを頻繁にリリースすることで、チームは発生した問題をより簡単に特定して修正することができます。 自働デプロイによりベストプラクティが促進される : ソースコードリポジトリにコミットされた変更は即座に自動プロセスによってデプロイすることができるため、チームはその変更が十分にテストされ、運用環境が厳重に監視されていることを確実にする必要があります。 継続的デプロイはどのように動くのか? 継続的デプロイは、ソフトウェアのリリースに関連する活動を調整する自動化されたパイプラインによって実行され、プロセスの可視性を提供します。プロセスの最中に、リリース可能な成果物が構築され、テストされ、パッケージ化され、本番環境にデプロイされます。リリース可能な成果物には、実行可能ファイル、スクリプトファイルのパッケージ、コンテナ、または最終的にプロダクションに配信されなければならないその他のコンポーネントが含まれます。 AWS CodePipelineは、新しいソフトウェアリビジョンができるたびにコードのビルド、テスト、およびデプロイを実行する継続的デプロイおよび継続的デリバリーのサービスです。 CodePipelineは、コード変更の統合、可視化を行い、ワークフローを介して最終的にユーザーの提供します。このパイプラインは、ソースコードリポジトリからのコード取得、ソースコードのビルド、テスト、および本番環境へのデプロイといったステージを定義し、これらのステージが順番に実行されること、障害が発生した場合には停止することを保証します。 CodePipelineはデリバリパイプラインを強化し、プロセスを統合しますが、ソフトウェア自体をビルドまたはテストする機能はありません。このステージでは、CodePipelineは、フルマネージドのビルドサービスであるAWS CodeBuildなど、いくつかのツールと統合されます。 CodeBuildはソースコードをコンパイルし、テストを実行し、デプロイする準備が整ったソフトウェアパッケージを生成します。このサービスは継続的なデプロイパイプラインの構築とテストに最適です。CodeBuildはDockerコンテナのビルドを含む多くの異なる種類のビルド環境をネイティブサポートしています。 コンテナは、予測可能で再現可能な環境を実現し、ある環境でテストされた変更が正常に展開できるという高いレベルの信頼性を提供するため、ソフトウェア提供の強力なメカニズムです。 AWSは、Dockerコンテナイメージを実行・管理するためのいくつかのサービスを提供しています。 Amazon ECSは、非常に高い拡張性とパフォーマンスを持つコンテナ管理サービスで、Amazon EC2インスタンスのクラスタ上でアプリケーションの実行環境を提供します。  Amazon ECRは、フルマネージドのDockerコンテナレジストリで、開発者は簡単にDockerコンテナイメージの格納、管理、およびデプロイが可能です。 最後に、CodePipelineはデプロイメントを容易にするために、AWS Elastic Beanstalk、AWS CodeDeploy、AWS OpsWorksや、AWS LambdaまたはAWS CloudFormationを使用した独自のカスタムデプロイメントコードやデプロイプロセスなど、いくつかのサービスと統合されます。これらのデプロイアクションを使用してパイプラインの最後に新しく構築された変更を本番環境にプッシュすることができます。 Amazon ECSへの継続的デプロイ これらのコンポーネントを組み合わせて、Dockerアプリケーションの継続的なデプロイパイプラインをECSに提供するためのリファレンスアーキテクチャを次に示します。 このアーキテクチャーは、CodePipelineを使用してECSおよびECRにコンテナをデプロイし、AWS上でフルマネージドの継続的デプロイパイプラインを構築する方法を示しています。この継続的デプロイのアプローチは、完全にサーバーレスであり、ソフトウェアの統合、ビルド、およびデプロイにマネージドサービスを使用します。 リファレンスアーキテクチャで作成されたパイプラインは、次のようになります。 このポストでは、このリファレンスアーキテクチャの各ステージについて説明します。開発者がランディングページの原稿を変更し、その変更をソースコードリポジトリにプッシュするとどうなるでしょう? まず、Source ステージでは、ソースコードリポジトリシステムにアクセスするための詳細がパイプラインに設定されます。リファレンスアーキテクチャでは、GitHubリポジトリにホストされているサンプルアプリケーションがあります。 CodePipelineはこのリポジトリをポーリングし、新しいコミットごとに新しいパイプラインを実行開始します。 […]

Read More

Raspberry Pi から、スーパーコンピューター、クラウドまで: Linux オペレーティングシステム

再び、Matthew Freeman および Luis Daniel Soto が、AWS Marketplace を通じた Linux の使用について説明します。 – Ana Linux は、ファイルサーバーからウェブサーバー、ネットワークセキュリティサーバーまで、すべての基礎として企業で幅広く使用されています。無料であること、そしてディストリビューションが商業的に利用可能であることが、多くのシナリオで当然のように選択される理由となっています。現在、Linux のディストリビューションは、小さな Raspberry Pi から世界最大のスーパーコンピューターまで、さまざまなマシンで利用されています。最小限およびセキュリティが強化された多様なディストリビューションがあり、その一部は GPU ワークロード向けに設計されています。さらに有用であるのは、クラウドベースのインフラストラクチャにおける Linux の使用です。その比較的軽量なアーキテクチャ、柔軟性、およびカスタマイズオプションにより、Linux はクラウド上の永続的なネットワークインフラストラクチャをはじめ、科学調査のコンピューティング負荷を処理する一時的な高パフォーマンスサーバーファームなどの特殊な用途に最適な選択となります。AWS は、Linux プラットフォームに対する独自の取り組みを示すため、AWS のサービスと緊密に連携した独自のバージョンの Linux を開発し、管理を継続しています。AWS は、AWS Marketplace を通じて、Linux およびオープンソースコミュニティのパートナーとなってきました。 これは、お客様がソリューションを構築してビジネスを営むのに必要なソフトウェアやサービスを簡単に発見、購入、デプロイできるマネージド型ソフトウェアカタログです。 お客様が簡単なクリック操作でユーザー契約を受諾し、価格オプションを選択して、ソフトウェアおよび関連 AWS リソースのデプロイを自動化できるようにすることで、ソフトウェアのライセンスと調達が簡略化されます。 検索およびフィルタリングにより、単独または他のコンポーネントと組み合わせて、ビジネスニーズに最適な Linux ディストリビューションを選択できます。 お客様用の Linux ディストリビューションの選択 Linux を初めて使用する場合、非常に多くのディストリビューションがあるため、戸惑うことがあります。使用するディストリビューションの決定はさまざまな要因によって影響を受けますが、お客様からは次のような考慮事項が重要であるという声が寄せられています。 Linux への既存の投資 (ある場合) Linux を初めて使用する場合は、すべてのオプションをかなり平等に検討する必要があります。 使用中の既存のプラットフォーム(オンプレミスネットワークなど) 社内ネットワークに接続する必要があるクラウドインフラストラクチャを追加する場合は、どの Linux ディストリビューションに必要なネットワーキングとアプリケーションコネクタがあるかを検討する必要があります。 複数のクラウドプラットフォームを使用する意図 […]

Read More

コストアロケーションタグがAmazon DynamoDBに対応しました

Amazon DynamoDBのテーブルにタグを設定可能になりました。タグは多くのAWSサービスでサポートしている、シンプルでユーザがカスタマイズ可能なキー・バリューのペアです。DynamoDBのタグ対応は DynamoDBの利用料金の可視化に有効です。テーブル毎にタグを設定でき、タグ毎に料金を参照出来ます。 様々な環境(development/staging/production)で複数のDynamoDBテーブルを持っているシナリオを例に上げてご説明します。DynamoDBテーブルにタグを設定出来ます。例として、keyにEnvironment、valueにDevelopment, Staging, Productionとそれぞれ設定します。 DynamoDBコンソールでどのように設定するか見ていきましょう。設定を行う前にListTagsOfResourceとTagResourceのAPI操作を行う適切な権限を持っているか確認をして下さい。 AWS Management Consoleにサインインをし、https://console.aws.amazon.com/dynamodb/からDynamoDBコンソールを開きます Tablesを選択し、設定を行ないたいテーブルを選択します Settingsタブで、Tagsをナビゲーションメニューから選択します Add Tagsセクションで、KeyにEnvironment、ValueにDevelopmentを入力し、Apply Changesをクリックします 標準の動作では、新しく追加されたキーはbillingでは無効化されています。以下の手順でBilling Consoleよりアクティベートを行えます: AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます ナビゲーションメニューからCost Allocation Tagsを選択します User-Defined Cost Allocation Tagsセクションから、タグキー内の Environmentタグ横のチェックボックスを選択し、Activateをクリックします アクティベート済みのコストアロケーションタグがある場合、AWS Cost Explorerからタグ付けされたAWSリソースのコストを簡単にブレークダウンして閲覧出来ます: AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます ナビゲーションメニューからCost Explorerを選択し、Launch Cost Explorerを選択します 左上のメニューからMonthly costs by serviceを選択し、右のメニュー内の Time rangeから閲覧したいタイムレンジを指定します Filteringセクション内のFilter byからTagを選択します タグキーのオートコンプリートフィールドから Environmentを選択、Developmentをタグバリューのオートコンプリートセクションから選択し、Applyをクリックします 指定したタグ(Environment=Development)でコストがフィルタリングされます。コストはタグをAWSリソースに指定した時点から表示されます DynamoDB Management Console, AWS CLIやAWS […]

Read More

AWS IoT Button Enterprise Program のご紹介

AWS IoT ボタンは 2015 年 10 月 に AWS re:Invent の AWS IoT サービスの発表で初めて IoT シーンに登場しました。その年の re:Invent の全参加者は、AWS IoT を実践する機会を提供する AWS IoT ボタンを受け取りました。その時以来、AWS IoT ボタンは、クリック可能な IoT デバイスに興味のあるすべての人に広く利用可能になりました。最近開かれた AWS re:Invent 2016 カンファレンスでは、AWS IoT Button Enterprise Program により企業向けの AWS IoT ボタンが公開されました。このプログラムは、物理的なボタンをクリックすることにより新しいサービスを提供したり、既存の製品を改善できるように企業を助けるためのものです。AWS IoT Button Enterprise Program では、企業はプログラム可能な AWS IoT ボタンを使用して、顧客エンゲージメントを高め、アプリケーションを拡張し、ユーザーエクスペリエンスを簡素化して、顧客に新しいイノベーションを提供することができます。IoT の力を活用することにより、企業は製品やサービスに対する顧客の需要にリアルタイムで対応することができ、シンプルなデバイスを通じて顧客に直接的なコミュニケーションを提供することができます。   AWS IoT Button Enterprise Program 新しい […]

Read More

RDS MySQL DBインスタンスからAmazon Aurora Read Replicaを作成可能になりました

24時間365日稼働しているアプリケーションが利用しているデータベースエンジンを他のデータベースエンジンに移行するにはいくつかの方法を使う必要があると思います。データベースをオフラインにせずに移行する良い方法として、レプリケーションを利用する方法があります。 本日、Amazon RDS DB for MySQLインスタンスを Amazon AuroraにAurora Read Replicaを作成して移行する機能をリリースしました。マイグレーションは、まず既存のDBスナップショットを作成し、そこからAurora Read Replicaを作成します。レプリカのセットアップが完了後、ソースデータベースとのレプリケーションの設定を行い最新のデータをキャッチアップします。レプリケーションラグが0になればレプリケーションが完了した状態です。この状態になった後に、 Aurora Read Replicaを独立したAurora DB clusterとして利用可能で、アプリケーションの設定を変更しAurora DB clusterに接続します。 マイグレーションはテラバイトあたり数時間かかります。また、6TBまでのMySQL DBインスタンスに対応しています。InnoDBテーブルのレプリケーションはMyISAMテーブルのレプリケーションよりもやや高速で、圧縮されていないテーブルの利点も受けられます。 RDS DBインスタンスをマイグレーションするためには、 AWS Management ConsoleからRDSのコンソールを選択し、Instance Actionsを選択します。その後、Create Aurora Read Replicaを選択するだけです: そして、データベースインスタンスの情報やオプションを入力し、Create Read Replicaをクリックします: コンソール上でマイグレーションの進捗状況を閲覧出来ます: マイグレーション完了後、Aurora Read Replicaでレプリカラグが0になるのを待ちます(SHOW SLAVE STATUSコマンドをレプリカで実行し、“Seconds behind master”を監視します)。その後、ソースのMySQL DBインスタンスへの新しいトランザクションを停止し、Aurora Read ReplicaをDBクラスタに昇格させます: 新しいクラスタが利用可能になるまで待機します(通常は1分程度): 最後に、アプリケーションの設定をクラスタのread/writeエンドポイントを利用するように設定し完了です! — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More

すぐに使用できるソリューション: AWS Marketplace のオープンソースソフトウェア

AWS Marketplace では、すばらしいことがたくさん起きています。こちらで、マーケットプレイスのオープンソースソフトウェアについての詳細を、Matthew Freeman および Luis Daniel Soto が説明します。 – Ana 業界の調査によると、企業が使用するオープンソースソフトウェア (OSS) は増加しています。ますます多くの企業の開発者は、現在進行中の開発作業の一環として、利用可能な OSS ライブラリを使用するように求めています。これらの開発者は、自分のプロジェクト (夜間および週末など) で OSS を使用していることがあり、その場合自然に別の場所でもそのツールおよびテクニックを使用したいと考えます。そのため、すべての部門の開発組織は、販売するソフトウェアだけでなく、自社の IT インフラストラクチャ内のアプリケーションにオープンソースソフトウェアを使用するケースを検討しています。この概要では、AWS を通したオープンソースソフトウェアの入手が開発および財務の観点から理にかなっている理由について説明します。 オープンソース開発プロセス オープンソースソフトウェアは、一般的に参加者の独立したコミュニティで開発されるため、ソフトウェアのバージョンの取得および管理は、通常オンラインコードリポジトリを通して行われます。異なるソースからのコードを使用すると、コードライブラリおよび開発ツールを取得して共に機能させることが困難となる場合があります。しかし、AWS Marketplace は、このプロセスをスキップして、必要な OSS で EC2 インスタンスを直接起動できます。AWS Marketplace には、OSS ソリューションの基盤として使用できる Linux のディストリビューションもあります。 構成済みのスタックが与えるメリット 市販のソフトウェアでこの 1-Click 起動機能は当然のことと考えるかもしれませんが、OSS にとって構成済みの AMI を実装していることには大きなメリットがあります。AWS Marketplace は、最も一般的なオープンソースソフトウェアの組み合わせ、または「スタック」を作成するソフトウェア会社に、これらのスタックを AWS クラウドに起動できる場所を提供します。TurnKey および Bitnami のような企業は、OSS のエキスパートを使って、ソフトウェアが共にうまく機能するようにこれらのコードスタックを設定および最適化します。これらの企業は、OSS のリリースを最新の状態に保ち、新しいバージョンが利用可能になるとすぐにスタックを更新します。これらの企業の中には、クラウドベースのサーバーの起動および管理をさらに容易にするために、クラウドホスティングインフラストラクチャを有料サービスとして提供しているものもあります。たとえば、オープンソースソフトウェアの最も一般的な組み合わせの 1 つは、LAMP スタックで、Linux […]

Read More