Amazon Web Services ブログ

Microsoft Windows Server と SQL Server 向けの新しくシンプルになった独自のライセンスエクスペリエンス

お客様は、Microsoft Windows Server および SQL Server の既存のライセンスを AWS に持ち込み、管理するための簡単な方法を提供するように求めています。本日、新しい、よりシンプルな、Bring-Your-Own-License (BYOL) エクスペリエンスを発表できることを嬉しく思います。 Windows Server または SQL Server インスタンスを起動するとき、お客様は従量課金モデルで AWS のライセンスを使用するか、既存の独自のライセンスを持ち込むことができます。AWS から取得したソフトウェアライセンスを使用する場合、お客様は複雑なライセンス契約条件を管理する必要のない、完全準拠の従量課金ライセンスモデルを取得します。本日発表された新しい BYOL エクスペリエンスにより、既存の Windows Server または SQL Server ライセンスを使用したいお客様は、EC2 で仮想マシンをシームレスに作成できます。その一方で、AWS はライセンスを管理し、お客様が指定したライセンスルールに確実に準拠するのをサポートします。 以前は、独自のサーバーごとのライセンスを持参する場合、キャパシティーを管理し、BYOL に必要な専用ホストを効果的に使用するために、追加の自動化を記述する必要がありました。このプロセスにより、ホストの管理があたかも EC2ではないようになり、AWS が提供するライセンスを使用する際の、シンプルで使いやすいエクスペリエンスとはまったく異なっていました。新しい BYOL エクスペリエンスは、ホストの割り当てやリリースなどの主要なホスト管理タスクを自動化し、ホストキャパシティーを管理し、ホストの Auto Scaling や自動リカバリなどの機能を有効にすることで、お客様のホスト管理エクスペリエンスをシンプルにします。その結果、他の EC2 インスタンスを作成するのと同じ方法で、専用ホスト上に BYOL インスタンスを簡単に作成できます。 ライセンスされたイメージを AWS クラウドに持ち込むための、新しくシンプルになったエクスペリエンスを見ていきましょう。この記事では、Windows Server ライセンスを使用しますが、Windows Server と SQL Server のライセンスを持ち込む場合も同じです。 ライセンス管理のセットアップ ライセンス画像をインポートして、Amazon […]

Read More

Amazon Transcribe Medical – ヘルスケア顧客向けのリアルタイム自動音声認識

2017 年、Amazon Transcribe がローンチされました。これは、開発者がアプリケーションに Speech-to-Text 機能を簡単に追加できるようにする自動音声認識サービスです。今日、Amazon Transcribe Medical で医療音声に拡張できることを非常に嬉しく思います。 私が子供の頃、両親は両方とも医師でしたが、秘書が後でタイプしてアーカイブできるように、夜はよくマイクロカセットレコーダーを使って手紙や試験報告書を記録していました。それはかなり前のことでしたが、ウィスコンシン大学とアメリカ医師会による 2017 年の調査によると、米国のプライマリケア医は 1 日 6 時間を電子医療記録 (EHR) システムの医療レポートへの入力に費やしているということです。EHR は現在、医療従事者の標準要件となています。 医師に紙のレポートに戻るべきだと主張する人は誰もいないと思います。デジタルデータを扱う方がはるかに効率的です。それでも、長時間かかるこれらの管理業務を軽減することはできるでしょうか? 浮いた時間を、患者を診たり、病院で多忙な一日を過ごした後の休憩に余分に当てたりした方がいいことに疑いはありません。 Amazon Transcribe Medical の紹介 Amazon Transcribe Medical のおかげで、医師は人間の介入なしに、臨床メモを簡単かつ迅速に口述し、音声を正確なテキストにリアルタイムで変換できるようになりました。臨床医は自然に話すことができ、「点」や「丸」といった句読点を明示的に発声する必要はありません。このテキストは、EHR システムなどのダウンストリームアプリケーション、またはエンティティ抽出のために などの AWS 言語サービスに自動的に送信できます。 完全マネージドサービスの精神で、Transcribe Medical はインフラストラクチャの作業から解放され、実際に使用した分だけ支払うだけで簡単にスケーリングできます。高価なライセンスの初期費用は発生しません! ご想像のとおり、Transcribe Medical も HIPAA に準拠しています。 技術的な観点からは、操作はデバイスのマイクを使用して音声をキャプチャし、一般的な Websocket プロトコルに基づいて PCM 音声をストリーミング API に送信することだけです。この API は、書き起こされたテキスト、および文字レベルのタイムスタンプと句読点などとともに、一連の JSON ブロブで応答します。オプションで、このデータを Amazon Simple Storage […]

Read More

アマゾン ウェブ サービス が BERT および Mask R-CNN における最速トレーニングタイムを達成

今日最も多く使用されている機械学習モデルには 2 つあります。自然言語処理 (NLP) 用の BERT と、画像認識用の Mask R-CNN です。AWS では、この数か月にわたり、これら 2 つの良く使われている先進的なモデルにおいて最短のトレーニング時間を達成するため、基盤となるインフラストラクチャ、ネットワーク、機械学習 (ML) フレームワーク、モデルコーディングなどに、大幅な改良を加えてきました。TensorFlow、MXNet、PyTorch に関しクラウド上でこれまで記録された最短のトレーニング時間を、本日、皆様と共有できることを、心から喜んでおります。お客様は、ご自身の TensorFlow、MXNet、PyTorch のモデルでのトレーニングに、これらのハードウェアとソフトウェアに関する最適化手法を、当社と同じ効率とスピードでご利用になれます。 モデルに対するトレーニング時間は、そのモデルの精度への改良を、素早く繰り返すときの作業性に直接影響します。トレーニング時間を削減しようとするときに最初に考えられる手法とは、GPU インスタンスの大規模なクラスターを通じて、トレイニングジョブを供給するということです。しかしこれでは、効率を高めることは困難です。大量のワーカーを通じてトレーニングジョブを供給しても、しばしば、急速にその効果が薄れてしまうことがあります。インスタンス間の通信におけるオーバーヘッドが、GPU を追加した分のコンピューティングパワーを帳消しにしてしまうからです。 BERT 現在、普及している NLP モデルである BERT、つまり Bidirectional Encoder Representations from Transformers は、当初は、いくつかの一般的な NLP タスクを処理するための最新手法として公開されたものです。 NVIDIA V100 GPU を 8 個使用する単一の Amazon EC2 P3dn.24xlarge インスタンスにおいて、TensorFlow と PyTorch を使いながらこの BERT をゼロからトレーニングするには、およそ 3 日間を要します。当社では、Elastic Fabric Adapter (EFA)を使用しつつ、このモデルを大規模クラスター上で集中させる方法を最適化しながら、P3dn.24xlarge インスタンスへの効率的なスケールアウトを実行し、3 […]

Read More

AWS Fargate 上の Amazon EKS を一般公開

本日より、皆さんは、Amazon Elastic Kubernetes Service を使用して、AWS Fargate の上でKubernetes ポッドを利用できます。Amazon EKS と Fargate は、AWS 上での Kubernetes ベースのアプリケーションの実行をわかりやすいものにします。ポッドを用意して、そのインフラストラクチャを管理する必要がなくなるからです。 AWS Fargate では、コスト最適化され、可用性の高いクラスターを稼働するのに、Kubernetes 運用の専門的な知識は必要ありません。Fargate は、お客様が Amazon EKS クラスターのためにEC2 インスタンスを作成し、管理する必要をなくします。 もはや、クラウド上で Kubernetes アプリケーションを実行するため、EC2 インスタンスのクラスターのパッチング、スケーリング、セキュア化の問題で頭を悩ませる必要はなくなります。Fargate を使えば、リソースを定義し、ポッドレベルでその支払いを行えます。これにより、アプリケーションごとに適切なサイズのリソースを利用することが容易になり、ポッドごとのコストを明確に知ることができます。 このブログの後半では、新しい機能を試してみて、Amazon EKS を Fargate 上で使用し、シンプルな Kubernetes ベースのアプリケーションをデプロイしてみましょう。 クラスターを構築する クラスタのセットアップを行う最も簡単な方法は、EKS の正式な CLI ツールである eksctl を使用することです。以下のコマンドは、ワーカーノードのない、demo-newsblog というクラスターを作成します。 eksctl create cluster –name demo-newsblog –region eu-west-1 –fargate この 1 行のコマンドは、実に多くのことを行います。クラスターを作成するばかりでなく様々な事柄を行いますが、とりわけ、Fargate […]

Read More

re:Invent 2019 12月4日のまとめ

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。re:Invent 2019 3日目(12月4日)が終了しました。本日は早朝からチャリティマラソン4K/8K Runがあり、多くの方がラスベガスの街を走っていました。 この後朝6時ごろ、多くの人が参加し会場はすごく混雑していました。 走り終わってさわやかな汗を流した人たちです。 そしてそのあと、Global Partner Summitのキーノートが行われました。 またWorkshopコーナーでは日曜の夜に発表されたDeep Composerを使ったワークショップが行われ、参加した方は実機を手に入れているようです。   それでは12月4日のまとめです。 Amazon Kinesis Video StreamsがWebRTCによる双方向のメディアストリーミングに対応しました WebRTCは、シンプルなAPIを介してWebブラウザー、モバイルアプリケーション、接続されたデバイス間のリアルタイム通信を可能にするオープンソースプロジェクトです。WebRTCを備えたKinesis Video Streamsを使用すると、開発者は、リアルタイムの双方向メディアストリーミングと、アプリケーションと接続されたデバイス間の双方向性を備えたアプリケーションを構築できます。 Amazon Neptune Workbenchがリリースされました グラフデータを照会するためのコンソール内エクスペリエンスであるWorkbenchがリリースされました。Jupyterノートブックを使用して、Neptuneデータベースをすばやく簡単に照会できます。これは、ライブコードとナラティブテキストを備えた完全に管理されたインタラクティブな開発環境です。 ノートブックは、SageMakerのノートブックサービスを通じてホストおよび請求され、インスタンスが準備完了状態にある間、ノートブックインスタンスに対して課金されます。 Amplify for iOS and Androidがプレビューリリースされました モバイル開発者がスケーラブルで安全なクラウドベースのサーバーレスアプリケーションを構築できるようにするオープンソースライブラリです。ライブラリを使用して、分析、AI / ML、API(GraphQLおよびREST)、データストア、ストレージなどの機能をモバイルアプリケーションに簡単に追加できます。Amplifyのエスケープハッチのサポートにより、生成されたiOSおよびAndroid SDKを追加のユースケースに使用できます。 Amazon Chime Meetings App for Slackがリリースされました SlackユーザーはAmazon Chime Meetings App for Slackを使用して、Slackワークスペースチャンネルと会話から直接Amazon Chimeオンライン会議を開始および参加できます。Amazon Chime Basicを使用すると、ユーザーは1対1の音声通話とビデオ通話を開始し、参加者としてグループ会議に参加できます。Amazon Chime Proへのアップグレードにより、Slackユーザーは、最大100人の参加者と16のビデオストリームでのグループ会議のホスト、会議リンクからのゲストアクセス、会議ダイヤルイン、SIPのサポートなど、Slackワークスペースから高度な会議機能にアクセスできます。Slackワークスペースの管理者は、Slack […]

Read More

サポート終了の Windows Server アプリケーションの将来を保証する新しい AWS プログラム

しばらく職務に従事していると、ビジネスに不可欠なレガシー Windows Server アプリケーションがあり、サポートされている新しいバージョンの Windows Server に移行できない状況に陥ることがあるかもしれません。お客様から、このレガシーアプリケーションを移動できない理由を数多く耳にしました。おそらく、アプリケーションが Windows Server の特定のバージョンに依存していたり、アプリケーションに関する専門知識を持っていなかったり、またインストールメディアやソースコードが失われた場合もあるかもしれません。 2020 年 1 月 14 日、Windows Server 2008 と 2008 R2 のサポートが終了します。サポートされていないバージョンの Windows Server でのみ実行できるアプリケーションを使用すると、セキュリティパッチの無料アップデートが入手できなくなり、セキュリティとコンプライアンスのリスクに対して脆弱になるため、問題があります。また、このようなアプリケーションを大幅なリファクタリングなしでクラウドに移行することも困難です。 サポートされていないバージョンの Windows Server でのみ実行されるレガシーアプリケーションがある場合、延長サポートにお金を使いたくなることもよくあります。ただし、これは単なる延命策に過ぎず、レガシーアプリケーションを将来にわたって保証する長期的なソリューションが必要だとの声がお客様から寄せられています。 当社には長期的な解決策があります これを支援するため、本日、AWS End-of-Support Migration Program (EMP) for Windows Server をローンチします。この新しいプログラムは、テクノロジーと専門家のガイダンスを組み合わせて、Windows Server の古いバージョンで実行されているレガシーアプリケーションを、AWS でサポートされている新しいバージョンに移行します。 Windows Server 2008 のサポート終了に対処することが迫られている場合、このプログラムから、判断を後日に後回しにするのではなく、長期的に問題を解決する独自のソリューションを受けられ、道筋が開けます。重要な点として、レガシーアプリケーションでコードを何も変更する必要はなく、元のインストールメディアやソースコードも必要ありません。 以下、このプログラムの技術的な部分がどのように機能するかを示します。ただし、移行を実際に行うには、AWS パートナーまたはプロフェッショナルサービスを利用する必要があることを頭に入れておいてください。[製品ページ] には、パートナーのネットワークが一覧表示されており、料金と特定の要件についてご相談いただけます。 それでは、これがどのように機能するかを見てみましょう。インストールメディアが利用できる場合にアプリケーションを移行するのにパートナーが実行するだろう手順について説明します。 Windows Server 2016 では、Microsoft SQL […]

Read More

Amazon SageMaker Processing – フルマネージドなデータ加工とモデル評価

2019年12月3日 Amazon SageMaker の新しい機能であり、データの前処理や後処理、モデルの評価といったワークロードをフルマネージドなインフラストラクチャの上で簡単に実行する機能である、Amazon SageMaker Processing を発表できることを嬉しく思います。 精度の高い機械学習(ML)モデルを学習するためには、多くの異なるステップを必要としますが、以下のようなデータの前処理より重要なものはないでしょう。 機械学習アルゴリズムが活用できる入力フォーマットへデータセットを変換 カテゴリカル特徴量のOne-Hot エンコーディングのような、既存の特徴量をさらに表現力の高い特徴量へ変換 数値型特徴量のリスケールや平準化 住所をGPSの座標に置き換えるような、高レベルな特徴量の作成 自然言語処理を適用するための文章のクリーニングやトークン化 これらのタスクは、データセットに応じて異なるスクリプトを実行することになり、そして、後で学習の際に使われるための加工済データを保存します。あなたが想像する通り、機械学習チームにとって、これらを手作業で行ったり、自動化ツールを構築してスケールさせることは魅力的なな計画とは言えません。同様のことが後処理ジョブ(フィルタリングや照合など)やモデル評価ジョブ(異なるテスト用データセットに対するスコアリング)にも言えるかも知れません。 これらの課題を解決するために、 Amazon SageMaker Proscessing が開発されました。より詳細をご紹介させて下さい。 Amazon SageMaker Processing の紹介 Amazon SageMaker Processing はデータサイエンティストと機械学習エンジニアが前処理、後処理、モデル評価といったワークロードを Amazon SageMaker 上で簡単に行うための新しい Python SDK を導入します。 この SDK はデータセットの変換のために使われるおそらく最も人気のあるライブラリである scikit-learn 向けの SageMaker の組み込みコンテナを使います。 必要に応じて、特定の Docker イメージに制限されることなく、独自の Docker イメージをお使い頂くことが出来ます。これにより、最大限の柔軟性を提供し、SageMaker Processing や Amazon ECS や Amazon Elastic Kubernetes Servicesなどの AWS […]

Read More

Amazon SageMaker Model Monitor – 機械学習モデルのためのフルマネージドな自動監視

2019年12月3日、Amazon SageMaker の新しい機能であり、本番環境にある機械学習 (ML) モデルを監視し、データの品質に問題が発生した場合には通知する、Amazon SageMaker Model Monitor を発表できることを嬉しく思います。 私がデータ関連の仕事を始めてから最初に学んだことは、データの品質に注意を払って払いすぎることは無いということでした。予期しない NULL な値を持ったデータや、特殊な文字エンコーディングがなされたデータベースに格納されていたデータによる問題の解決に数時間かかった経験がある人は挙手して下さい。 モデルは文字通り大量のデータから構築されるため、機械学習の実践者がなぜ多くの時間を、データセットの確認に時間を使うのかは容易に理解できます。特に、彼らは学習用データセット(モデルの学習に使われる)と、評価用データセット(精度を測るのに使われる)のデータサンプルが同じ統計的な特徴を持っていることを確認します。 そこに魔物がいます!実験に使われるデータセットを完全にコントロールしたとしても、構築したモデルが受け取るであろう、現実世界のデータが同じようにコントロールされるとは言えません。もちろん、現実世界のデータはきれいではないでしょうし、もっと気にかかるのは、受け取るデータの統計的特徴量が徐々に変化するような、データドリフトです。最小値、最大値、平均、分散など、これらの属性は、モデルが学習されている間の仮説や決定を形作ります。これらの値の重大な変化が、推論の精度に影響を与えることは、直感的に感じることができるでしょう。ローン審査予測において、入力データのドリフトや、たとえそれが欠損であったとしても、より多くの額を予測することを想像して下さい。 これらの条件を検知することはとても難しいことです。モデルによって受け取られるデータを捕捉する必要があり、学習用データと比較するために全ての統計解析を行い、ドリフトの発生を検知するルールを定義し、発生した場合にはそれを通知する、といったことをモデルを更新する度に行う必要があります。機械学習実践の専門家は、これらの複雑なツールを開発する方法を確かに知っているでしょうが、多くの時間と労力が必要になります。Undifferentiated heavy lifting が再び襲いかかってきます。 これらの負荷を減らし、お客様が価値創造に集中することを助けるために、我々は Amazon SageMaker Model Monitor を開発しました。詳細をお伝えさせて下さい。 Amazon SageMaker Model Monitor の紹介 典型的なモデル監視は以下のようになります。最初に 既存のもの、もしくは監視を目的に作られた新しいもの、どちらかの SageMaker エンドポイント を開始するところから始めます。Model Monitor は組み込みアルゴリズム、組み込みフレームワーク、独自コンテナのいずれかであっても、どのようなエンドポイントに対して使うことが出来ます。 SageMaker SDK を使うことによって、エンドポイントへ送付される設定可能なデータを捕捉する(要望に応じて推論結果についても捕捉することができます)ことができ、Amazon Simple Storage Service (S3) バケットを保存することができます。捕捉されたデータはメタデータ(コンテンツタイプやタイムスタンプなど)が付与され、他の S3 オブジェクトと同様に保護とアクセスをすることができます。 その後、エンドポイントにデプロイされているモデルを学習するときに使われるデータからベースラインを作ります(もちろん既存のベースラインを再利用することも可能です)。これは Amazon SageMaker Processing ジョブを起動します。これは Model Monitor が下記のような処理を行うものです。 入力データのスキーマ、例えばタイプやそれぞれの特徴の完全性についての情報を予想します。必要に応じて見返したり、更新することができます。 […]

Read More

世界一目指して走れ! ~AWS DeepRacer Championship Cup @AWS re:Invent 2019 – Part 1-

2019年、多くの注目を集めたAWS DeepRacerリーグはre:Invent 2019でいよいよ最終章へ突入しました。 各地のAWS Summitやバーチャル リーグで勝ち抜いたレーサーたちがラスベガスに集結し、さらにre:Inventで開催される3つのレースで構成されたコンペティション[Championship Cup」で厳しい競争を勝ち抜いたのちに世界一が決まります。ファイナリストとしてクオリファイされたのは世界各国から64名。そのうち日本からは8名が参戦しています。 簡単に世界一になるまでの流れを説明します。 まず、世界一になるためにはre:Invent 2019の中で開催される3回のコンペティションで勝たなければなりません。さらに、使用するコースもこれまでと異なる形状のものとなり、難易度が各段に上がっています。 初戦は「The Qualifying 64 Group racing」 MGM Grand Arenaで6面のトラックを使って行われる初戦では、64名を4つのグループに分け最速タイムを競います。 一人4分の持ち時間のレースを4回行い、合計16分走ります。その中で最も速いラップタイムが記録となります。なぜ4回も?これには理由があります。限られた時間内で多数のレースを展開するには複数トラックが必要になりますが、物理的なトラックにはそれぞれ微妙な「くせ」があります。ほんの少し傾斜していたり、Wifiの状態が異なっていたり、条件は全く同一というわけにはいきません。より公平な評価が可能なレース環境とするためこのような形がとられているのです。 そして、各グループの上位4位、16名が次のステージに進みます。 2戦目は「Bracket of 16 racing」 これまでのレースはシンプルに全参加者でタイムを競う形式をとっていましたが、このBracket of 16 racingでは、「対戦相手」のいるトーナメント形式をとります。ぶっちぎりの速さでなくてもよく、ただ対戦相手より0.01秒でも速ければ勝ちです。 トーナメントで3回勝てば決勝戦へと進むことができます。決勝に進むのは3名です。 そして最後の決戦となる「The final 3 showdown」 re:Invent Day4のKeynote直前に開催されるこのレースは、会場をVenetianに移して行われます。 このレースはWerner Vogelsのキーノートの直前に実施され、結果はKeynote内で発表されます。まさにこの1年の戦いの最終決戦にふさわしい大舞台が用意されたと言えるでしょう。これまでのレースと異なり、一人当たりの持ち時間はたったの90秒。この短い時間の中で有効ラップであり、なおかつ速いタイムが求められます。 そして12月3日、初戦の「The Qualifying 64 Group racing」が行われ、 日本から参加された3名の方がみごと「Bracket of 16 racing」に進出されました! ・グループB:Sola@DNP こと 瀧下 初香さん (9.056秒 グループ1位) ・グループC:nero-DNPds こと相場 武友さん(9.955秒 グループ4位) ・グループD:Fumiaki […]

Read More

新機能 – AWS ECS Cluster Auto ScalingによるECSクラスターの自動スケーリング

本日、AWS ECS Cluster Auto Scalingを発表します。この機能は、スケールアウトを高速化し信頼性を向上させる、クラスター内の空きキャパシティ管理の提供と、スケールイン時に終了されるインスタンスの自動管理を提供し、クラスターの自動スケーリングをより使いやすいものにします。 ECS Cluster Auto Scalingを有効にするには、Capacity Providerと呼ばれる新たな項目を設定する必要があります。1つのCapacity Providerは1つのEC2 Auto Scaling Groupに関連づきます。あるAuto Scaling GroupにECS Capacity Providerを関連付け、ECSクラスターにCapacity Providerを追加すると、ECSの次の2つの新機能を用いてクラスターを自動スケールできるようになります。 管理されたスケーリング。Capacity Provider Reservationという新しいメトリックに対応するスケーリングポリシーが自動的に生成され、Auto Scaling Groupにアタッチされます。 管理されたインスタンス保護。スケールイン時にコンテナーからインスタンス終了を把握できるようになります。 これらの新機能により、ECSクラスターのスケールイン・スケールアウト時の制御が可能になります。 Capacity Provier Reservation Capacity Provider Reservationと呼ばれる新しいメトリックを導入します。クラスター内のすべてのECSワークロード、つまり既存のもの、新規のもの、変更になるもの、これらすべてが必要とする、クラスターリソースの割合(パーセンテージ)が計測されます。このメトリックはCPUやメモリ使用率を用いるよりも確度の高い、素早いスケールアウトを実現するために用いられ、またクラスター内の空きキャパシティを把握することもできるようになります。また、インスタンスを新規起動せず追加のコンテナーを素早く起動できるか、といった判断も可能になります。 管理されたインスタンス保護 インスタンス保護機能により、スケールインに際してどのインスタンスを削除できるかをECSに知らせることができます。これにより稼働中のコンテナーの中断を最小限に抑えられるようになります。運用コストの最適化、またECSで稼働するコンテナーワークロードの可用性向上に役立つ機能です。 ユーザーの利点 これまで、自動スケールするコンテナーワークロードを運用していたユーザーは、多くの場合、メトリックベースのスケーリングを使っていました。メトリックの例にはCPU使用率やメモリ使用率といったものがあり、この変化に基づいてクラスターインスタンスを追加、あるいは削除するべきかを判断するスケーリングポリシーを定義していました。 単一のワークロード、もしくは穏やかに負荷が上昇するワークロード群であれば、この方式でもうまくいく場合が多かったと考えます。しかし同一クラスター上で複数種類のワークロードを稼働させるケース、また急激な負荷上昇が見込まれるワークロードに対しては、スケーリングの問題が頻発していました。理想的には、その時点のクラスターサイズで収容しきれないようなワークロードの増加に対しては、クラスターサイズをスケールアウトさせるようなスケーリングポリシーが必要です。 既存のメトリクスがコンテナー全体を対象にしたものではなく、またその時点で使用中のリソースのみを表現するものである以上、スケールアウトが緩慢に、また不安定になってしまうことは避けられませんでした。加えて、クラスター内のどこでコンテナが稼働しているのかをスケーリングポリシーが把握できないため、スケールインに際して不用意にコンテナーを終了させてしまう場合もありました。この問題はコンテナーワークロードの可用性を低下させる要因になっていました。コンテナーインスタンスの追加台数の準備、追加のスクリプト開発、あるいは手動運用などでの回避は、すべて運用コストの増大を招いていたと言えます。 スケールしてみよう! この機能をよく理解するには手を動かしてみるのが一番だと思います。 Amazon ECS Cluster Auto Scalingは、マネジメントコンソール、AWS CLI, Amazon ECS APIのいずれからも操作可能です。この例ではAWS CLIを用い、ターミナルからクラスターを作成する流れを見ていきます。 まず2つのファイルを作成します。ひとつ目はdemo-launchconfig.jsonで、EC2 Auto Scaling Groupに起動するAmazon Elastic […]

Read More