Amazon Web Services ブログ

Category: Launch

New – Amazon AppFlow のご紹介

Software as a service (SaaS) アプリケーションはお客様にとってますます重要になり、それを採用するお客様も急速に増えてきています。このソフトウェアの利用方法には多くの利点がありますが、1 つの課題は、データがさまざまな場所に点在していることです。データから有意義な洞察を得るには、それを分析する方法が必要ですが、データが複数のデータアイランドに分散している場合は困難な場合があります。 開発者は膨大な時間をかけてカスタム統合を行い、SaaS アプリケーションと AWS のサービスの間でデータを渡して分析できるようにしています。これには高額の費用がかかり、完了までに数か月を要する場合もあります。データ要件が変更されると、統合に複雑な変更を加える必要があり、費用もかかります。潤沢なエンジニアリングリソースがない企業は、アプリケーションからデータを手動でインポートおよびエクスポートすることになるかもしれません。これは時間がかかり、データ漏洩のリスクがあり、人為的ミスを招く可能性もあります。 本日、この問題を解決する Amazon AppFlow と呼ばれる新しいサービスを発表できることを嬉しく思います。Amazon AppFlow を使用すると、AWS のサービスと、Salesforce、Zendesk、ServiceNow などの SaaS アプリケーション間のデータフローを自動化できます。SaaS アプリケーション管理者、ビジネスアナリスト、および BI スペシャリストは、IT が統合プロジェクトを完了するのに数か月待つことなく、必要な統合のほとんどをすばやく実装できます。 SaaS アプリケーションから AWS のサービスへのデータフローを可能にするだけでなく、AWS のサービスから SaaS アプリケーションへのデータの送信も行えます。AWS ではセキュリティが最優先事項であるため、すべてのデータは転送時に暗号化されます。一部の SaaS アプリケーションは AWS PrivateLink と統合されています。これにより、セキュリティとプライバシーがさらに強化されます。AWS PrivateLink を使用して SaaS アプリケーションと AWS の間でデータの送受信が行われる場合、トラフィックはパブリックインターネットを使用せずに Amazon ネットワークに留まります。SaaS アプリケーションがサポートしている場合、Amazon AppFlow が自動的にこの接続を処理し、プライベートデータの転送を誰にとっても簡単にし、インターネットベースの攻撃による脅威と機密データ漏洩のリスクを最小限に抑えます。 データ転送をスケジュールに従って、ビジネスイベントに応じて、またはオンデマンドで実行するようにスケジュールできます。これにより、データの共有を迅速かつ柔軟に行うことができます。 この新しいサービスの力を示すために、簡単なフローの構築方法を示します。 筆者はイギリスとアイルランドでウェブコミュニティのオーガナイザー向けに Slack ワークスペースを運営しています。Slack は […]

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

AWS Fargate Spotの発表 – Fargateとスポットインスタンスの統合

本日のAWS re:Invent 2019にて、AWS Fargate Spotを発表します。Fargate SpotはAWS Fargateの新しい機能です。中断に強いAmazon Elastic Container Service (Amazon ECS)タスクに最適であり、Fargate価格から最大70%割引で提供します。 もしEC2スポットインスタンスを知っていれば、同様のコンセプトで理解できます。Fargate Spotは、AWSクラウドの空きキャパシティを活用してタスクを実行します。Fargate Spotが空きキャパシティを確保できるかぎり、ユーザーは指定したタスクを起動することができます。AWSにキャパシティが必要になったとき、Fargate Spotで稼働するタスクは2分前の通知とともに中断されることになります。Fargate Spot用のキャパシティが使用できなくなると、Fargateは稼働中の通常のタスクを保持しながら、Fargate Spotで稼働するタスクをスケールダウンします。 タスクが中断される可能性があるという特性から、中断が許容できないワークロードをFargate Spotで稼働させるべきではありません。一方で中断耐性のあるワークロードに対しては、コスト最適化に大きく貢献します。 Fargate Spotは特に画像のレンダリング、モンテカルロシミュレーション、ゲノム解析といった並列度の高いワークロードに適しています。また高可用性を求められるウェブサイトやAPIサーバーのように、ECSサービスの一部となるタスクに対してもFargate Spotを適用することができます。 クラスター定義を作成・更新する際、常時稼働させるべき最低限のタスク数を指定し、さらに性能向上を狙いとするタスクをコスト効率の良いFargate Spot上で稼働するように構成することができるようになります。サービス定義のService Auto Scalingを利用することで、Fargate Spot用のキャパシティが使用可能になり次第、リクエストを満たすようにスケジューラーがタスクを起動し、Fargate Spot用のキャパシティが使用できなくなると、前述の通り先に指定した常時稼働タスクを保持しながら、Fargate Spotで稼働するタスクがスケールダウンする、という動作を実現することもできます。 AWS Fargate Spotの開始方法を見ていきましょう。 まずECSマネジメントコンソールより、新規のECSクラスターを作成します。Fargate起動タイプを選択するため、ここでは”Networking only”を選択し、ウィザードを進めます。 クラスターが作成されたらば、”Capacity Providers”タブからキャパシティプロバイダーを追加します。デフォルトではFARGATEとFARGATE_SPOTの2種類のキャパシティプロバイダーが用意されています。 キャパシティプロバイダーとしてFARGATE_SPOTを用いるのに、まずデフォルトのプロバイダーをFARGATE_SPOTに変更します。”Update Cluster”ボタンをクリックし、次の画面で”Add provider”をクリックしてFARGATE_SPOTを追加し、Updateボタンを押します。 続いて、これまでのようにタスクを起動します。事前に設定済みのタスク定義から、10のタスクを指定し、また”VPC and security groups”セクションでVPC関連の必要情報をセットしたのちに”Run Task”をクリックします。 起動された10個のタスクは、通常のFargate環境ではなくFargate Spot環境が選択されています。あるタスクをクリックしてみると、実際にキャパシティプロバイダーとしてFARGATE_SPOTが使用されたことがわかります。 ここまで、Fargate Spotの開始方法を紹介してきました。ぜひお手元でも試してみてください。 数週間前にCompute Savings Plansをリリースしました。FargateはCompute Savings Plansの一部に含まれます。さらにここでFargate Spotが登場したことより、費用の大幅な効率化とともに、様々な種類のアプリケーションへの一層の活用が期待できます。いま、Fargateを使うのにまたとないチャンスが訪れていると言えるでしょう。 […]

Read More

Amazon SageMaker Debugger – 機械学習モデルのデバッガ

2019年12月3日、機械学習(ML)学習時に起こる複雑な問題を自動的に識別する Amazon SageMaker の新しい機能、Amazon SageMaker Debugger を発表できて非常にうれしく思います。 機械学習モデルの構築と学習は、サイエンスと工芸の融合です(魔術と言う人もいます)。データセットの収集から準備、さまざまなアルゴリズムの実験、最適なトレーニングパラメーター(恐ろしいハイパーパラメーター)の探索まで、機械学習を実行する人は高性能のモデルを提供するために多くのハードルをクリアする必要があります。これがまさに、機械学習ワークフローを簡素化し高速化する、モジュール式のフルマネージドサービス Amazon SageMaker を構築する理由なのです。

Read More

AWS Transit Gatewayにマルチキャストとインターリージョンピアリング機能を追加

AWS Transit Gateway は、1 つのゲートウェイを使用して、数千の Amazon Virtual Private Cloud(VPC)とオンプレミスネットワークを接続できるサービスです。 お客様は、このサービスがもたらす運用コストの削減と全体的なシンプルさを享受しています。 さらに、本日(2019/12/03) AWS Transit Gateway インターリージョンピアリングと AWS Transit Gateway マルチキャストという 2 つの新機能がリリースされました。 ピアリング お客様がAWSでワークロードを拡張するときに、複数のアカウントやVPCにまたがってネットワークを拡張する必要があります。お客様は、VPCピアリングを使用して VPC のペアを接続するか、PrivateLink を使用して VPC 間でプライベートサービスエンドポイントを公開することができます。 しかし、この管理は複雑です。 AWS Transit Gateway インターリージョンピアリングでは、これに対処し、複数のAWSリージョンにまたがるセキュアでプライベートなグローバルネットワークを簡単に作成できます。 インターリージョンピアリングを使用すると、組織内の異なるネットワーク間で一元化されたルーティングポリシーを作成し、管理を簡素化し、コストを削減できます。 インターリージョンピアリングを流れるすべてのトラフィックは匿名化、暗号化され、AWS バックボーンによって伝送されるため、リージョン間の最適なパスが常に最も安全な方法で確保されます。 マルチキャスト AWS Transit Gateway Multicast を使用すると、クラウドでマルチキャストアプリケーションを構築し、接続された数千の仮想プライベートクラウドネットワークにデータを配信することが容易になります。 マルチキャストは、単一のデータストリームを多数のユーザーに同時に配信します。 これは、ニュース記事や株価などのマルチメディアコンテンツやサブスクリプションデータをサブスクライバーグループにストリーミングするための好ましいプロトコルです。 AWS は、お客様がアプリケーションをクラウドに移行し、AWS が提供する伸縮自在性と拡張性を活用できるようにするネイティブのマルチキャストソリューションを提供する最初のクラウドプロバイダーです。今回のリリースでは、Transit Gatewayにマルチキャストドメインが導入されました。 ルーティングドメインと同様に、マルチキャストドメインを使用すると、マルチキャストネットワークを異なるドメインにセグメント化し、Transit Gateway を複数のマルチキャストルーターとして動作させることができます。 今すぐ利用可能 これら2つの新機能は準備ができており、今日あなたが試すことを待っています。 インターリージョンピアリングは、米国東部 (バージニア北部)、米国東部 […]

Read More

Amazon Redshift の新機能 – データレイクエクスポートとフェデレーテッドクエリー

データウェアハウスは、トランザクション系システムや業務アプリケーションから届いたリレーショナルデータの分析に最適化されたデータベースです。Amazon Redshiftは高速でフルマネージドのデータウェアハウスであり、標準SQLや既存のビジネスインテリジェンス(BI)ツールを用いたデータ分析をシンプルかつ効率的に行うことを可能にします。 データウェアハウス内に格納されていないであろう非構造化データから情報を習得するためには、データレイクを構築するという手段があります。データレイクは、全ての構造化データと非構造化データをあらゆるスケールで格納可能な、一元化されたレポジトリです。Amazon Simple Storage Service (S3)上に構築されたデータレイクによって、ビッグデータ分析を行い、機械学習を用いて準構造化データセット(JSON、XMLなど)や非構造化データから知見を得ることが簡単に行えるようになります。

Read More

Amazon SageMaker Studio: 機械学習のための初の統合開発環境

2019年12月3日、Amazon SageMaker Studioという機械学習のための初の統合開発環境(IDE)を提供できることを非常に嬉しく思います。 2017年に Amazon SageMaker がリリースされてからしばらく経ち、このサービスをご利用いただいているお客様の数は増加しています。機械学習開発ワークフローには反復的なプロセスが必要ですが、機械学習ツールが成熟していないために開発者は大変な思いをしてきました。従来のソフトウェア開発時に開発者が当たり前に使用する多くのツール(デバッガ、プロジェクトマネジメントツール、コラボレーション機能、モニタリングツールなど)は、まだ機械学習用には存在していないのです。

Read More

Amazon SageMaker Experiments – 機械学習モデルの整理、追跡、比較、評価

2019年12月3日、機械学習(ML)実験とモデルバージョンの整理、追跡、比較、評価を可能にする Amazon SageMaker の新機能である、Amazon SageMaker Experiments を発表できて非常にうれしく思います。 機械学習では非常に多くの反復プロセスを含みます。1つのプロジェクトの過程で、データサイエンティストと 機械学習エンジニアは、最大限の精度を求めて数千の異なるモデルを定期的に学習を行います。実際、アルゴリズム、データセット、および学習パラメーター(別名ハイパーパラメーター)の組み合わせの数は無限に存在します。それはまさに「干し草の山の中にある1本の針を探す」ということわざのように無駄骨を折る苦労を伴います。

Read More

まもなく登場 – Graviton2プロセッサ搭載の汎用、コンピューティング最適化、メモリ最適化インスタンス

昨年のre:Invent 2018では、ArmベースのGravitonプロセッサ搭載の初代EC2インスタンス(A1)を発表しました。以来、コンテナ化されたマイクロサービス、ウェブサーバー、ログ等のデータ処理といったスケールアウト型のワークロードに対して、何千もの顧客がA1インスタンスを活用しています。 ArmアーキテクチャとA1インスタンスは早期の段階から、OSベンダー、ソフトウェアベンダー双方のコミュニティの強い協力を得られています。今やA1インスタンスに対して、Amazon Linux 2, Ubuntu, Red Hat, SUSE, Fedora, Debian, FreeBSDといった複数のLinux/Unixディストリビューションを選択できます。 さらに稼働させるサービスとしてDocker, Amazon ECS,  Amazon Elastic Kubernetes Serviceといったコンテナサービスを選択できますし、他にも多くのシステムエージェントや、AWS Developer ToolsやJenkinsを始めとする様々な開発ツールも動作します。 これまでにA1インスタンスに寄せられたフィードバックは強力かつポジティブなものばかりで、特にCPUインテンシブあるいはメモリインテンシブなワークロードをどんどんArmベースのサーバーで稼働させていきたいという声を受け取っていました。 Graviton2 本日、次世代のARMベースのEC2インスタンスの登場を先行発表します。このインスタンスはAWS Nitro Systemをベースに、新しいGraviton2プロセッサを搭載したものです。このプロセッサは7nm(ナノメートル)製造プロセスによるAWS独自設計によるもので、64ビットARM Neoverseコアをベースとして、浮動小数点演算処理の2倍の性能向上を含め、最大でA1インスタンスの7倍の性能を発揮するものです。また追加のメモリチャネルと1コアあたり倍加したキャッシュにより、メモリアクセス速度は最大で5倍まで向上しました。 これらの改良は、これまでのM5, C5, R5といった第5世代のインスタンスタイプを上回る、極めて大きな性能向上をもたらします。vCPUあたりの性能をM5インスタンスと比較したとき、初期のベンチマーキングでは次のような結果が得られました。 SPECjvm® 2008: +43% (推定) SPEC CPU® 2017 integer: +44% (推定) SPEC CPU 2017 floating point: +24% (推定) NginxでのHTTPSロードバランシング: +24% Memcached: +43% かつレイテンシの短縮 X.264ビデオエンコーディング: +26% Cadence XcelliumによるEDAシミュレーション: […]

Read More