Amazon Web Services ブログ

Category: Compute

SAP on AWS最新情報 – お客様ケーススタディ、スケールアップ、スケールアウトほか

SAP SAPPHIRE NOW 2019が今週フロリダで開催されます!私のAWSの同僚もたくさん現地にいるでしょう。そして、彼らは皆さんと喜んで会話したいと思っています。今日は、SAPが推進するOLTPとOLAPのエンタープライズワークロードを稼働するのにAWSが最適な環境であることを確かめるために、私たちが実施してきた取り組みについて、いくつかのお客様のサクセスストーリーを共有し、簡潔な最新情報をお知らせします。

Read More

データカタログと ETL ジョブの AWS Glue トリガーを使用してサーバーレスデータレイクを構築および自動化する

今日、データは、IoT センサー、アプリケーションログ、クリックストリームなどのリソースの非構造化データ、トランザクションアプリケーション、リレーショナルデータベース、スプレッドシートの構造化データなど、あらゆる場所から流れています。データはすべてのビジネスにとって非常に重要な部分になりました。そのため、データから迅速にデータを抽出するために、信頼できる唯一の情報源を維持し、データの取り込みから変換、分析まで、パイプライン全体を自動化する必要があります。 データ量、速度、種類が増えるにつれて、データ分析の複雑さに対する懸念が高まっています。この懸念は、データをビジネスユーザーが使用できる状態にするために必要な手順の数と複雑さから生じています。多くの場合、データエンジニアリングチームは、パイプラインの構築と、その抽出、変換、ロード (ETL) の最適化に時間を費やしています。プロセス全体を自動化することで、価値実現までの時間と運用コストを削減できます。この記事では、完全に自動化されたデータカタログと ETL パイプラインを作成してデータを変換する方法について説明します。 アーキテクチャ この記事では、以下のアーキテクチャを構築して自動化する方法を学びます。 プライマリデータストアとして Amazon Simple Storage Service (Amazon S3) を使用して、サーバーレスデータレイクを構築します。Amazon S3 のスケーラビリティと高可用性を考えると、データの信頼できる唯一の情報源として最適です。 Amazon S3 にデータを取り込み、保存するためにさまざまな手法を使用できます。たとえば、ストリーミングデータを取り込むために Amazon Kinesis Data Firehose を使用できます。既存のデータベースからリレーショナルデータを取得するために AWS Database Migration Service (AWS DMS) を使用できます。また、AWS DataSync を使用して、オンプレミスのネットワークファイルシステム (NFS) からファイルを取り込むこともできます。 取り込まれたデータは Amazon S3 バケットに入り、これを raw ゾーンと呼びます。そのデータを利用できるようにするには、そのスキーマを AWS Glue のデータカタログに登録する必要があります。これを行うには、Amazon S3 トリガーによって呼び出される AWS Lambda 関数を使用して、データをカタログ化する AWS Glue クローラを起動します。クローラによるテーブル定義の作成が完了したら、Amazon […]

Read More

Serverless Tech/事例セミナー(2019年3月27日 実施) レポート Vol.3

2019年3月27日 実施のセミナーのレポート 3部編の Vol.3 です。他の回は以下のリンクよりアクセスください。 Vol.1 : 手段先行でも悪くはない!Ruby on LambdaではじめるServerless Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [本記事]     Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [資料はこちら] クラスメソッド株式会社 和田祐介氏

Read More

[AWS Black Belt Online Seminar] Amazon VPC Advanced 資料及び QA 公開

先日 (2019/4/17) 開催しました AWS Black Belt Online Seminar「Amazon VPC Advanced」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190417 AWS Black Belt Online Seminar Amazon VPC Advanced AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Transit Gatewayが使えるようになった今、Virtual Gatewayを用いたVPN・DXを敢えて採用するようなケース・利点はあるものでしょうか A. VPC間で通信しない、従来通りのユースケースでは引き続き有効です。Transit Gatewayは機能が多い代わりに通常のVPN/DXとVGWを使うものよりコストがかかりますので、比較検討することが重要になります。https://aws.amazon.com/jp/transit-gateway/pricing/ Q. VPC Sharing にはAWS Organizationsが必要とのことなのですが、一括請求機能の利用だけで要件を満たすのでしょうか? A. いいえ。一括請求機能では要件を満たしません。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html#vpc-share-prerequisites より — 共有 VPC の前提条件 組織のマスターアカウントで、リソース共有を有効にしておく必要があります。リソース共有の有効化の詳細については、AWS RAM User Guide の「AWS Organizations での共有の有効化」を参照してください。 — Q. P.39 TransitGatewayのVPC-CIDRとProduction, TestingといったVPC-CIDRは、従来のVPC運用と同じように分けて考える認識であっていますか?TransitGatewayのVPC-CIDRを広めに取って、その中で個々のVPCを定義しない認識であっていますか? […]

Read More

Serverless Tech/事例セミナー(2019年3月27日 実施) レポート Vol.2

2019年3月27日 実施のセミナーのレポート 3部編の Vol.2 です。他の回は以下のリンクよりアクセスください。 Vol.1 : 手段先行でも悪くはない!Ruby on LambdaではじめるServerless Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 [本記事] Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方     Ruby on Lambdaで変わる大規模サービスの裏側 [資料はこちら] Sansan株式会社 Eight事業部 Engineering Group/エンジニアリングマネージャー 藤井洋太郎氏

Read More

Serverless Tech/事例セミナー(2019年3月27日 実施) レポート Vol.1

「AWS re:Invent 2018」では多くのサーバーレス関連のアナウンスがありました。その中でも、Ruby や COBOL を始めとする開発言語対応の拡張やカスタムランタイム、共有ライブラリ管理機能(Layers)は、サーバーレスの成熟と広がりを感じさせるものでした。特に、日本で利用者の多い Ruby は長い間望まれていたことから、プロジェクトでの適用が急速に進みはじめています。 そこで、すでに利用し始めていただいているお客様として、ヴァル研究所様およびSansan様に2019年3月27日に実施のServerless Tech/事例セミナーで登壇いただき、その経験を共有いただきました。開発言語としてのRubyに対する熱い想いやモチベーションが伝わる講演内容でした。また、これからサーバーレスを検討される参加者のために、従来型開発との考え方の違いを、開発の観点からクラスメソッド様より説明がありました。 Vol.1 : 手段先行でも悪くはない!Ruby on LambdaではじめるServerless [本記事] Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方     手段先行でも悪くはない!Ruby on LambdaではじめるServerless [資料はこちら] 株式会社ヴァル研究所 マーケティングテクノロジー部 CB開発チーム 福本江梨奈氏

Read More

Docker、Amazon ECS、スポットフリート: 素晴らしい組み合わせ

AWS コンテナのヒーロー、Tung Nguyen による寄稿。Tung は、AWS のクラウドインフラストラクチャとソフトウェアに焦点を当てたコンサルティング会社、BoltOps の社長兼創立者です。また、BoltOps Nuts and Bolts ブログの執筆も楽しんでいます。 EC2 スポットインスタンスでは、大幅な割引で予備の計算容量を使うことができます。Amazon ECS をスポットインスタンスと共に使用することは、おそらく AWS でワークロードを実行するための最良の方法の 1 つです。スポットインスタンスを使用すると、Amazon EC2 インスタンスで 50 ~ 90% を節約できます。この話を聞いたら、ブラックフライデー特別割引のような大きなチャンスに飛び込みたいと思うでしょう。しかし、ほとんどの人はスポットインスタンスについて知らないか、ためらってしまいます。これは、スポットに関するいくつかの誤った認識が原因である可能性があります。 スポットに対する誤った認識 スポットモデルでは、AWS はいつでもインスタンスを削除できます。これは、メンテナンスのアップグレード、そのインスタンスタイプに対する高い需要、古いインスタンスタイプ、または何らかの理由によるものである可能性があります。 そのため、人々はスポットに対して、最初はすぐ恐怖や誤った認識を持つようになります。 インスタンスをいつでも置き換えることができるというのは、どういう意味ですか? いいえ、インスタンスを起動してから 20 分以内に抹消されるという意味です。 私も最初は同じように感じました。実際、スポットインスタンスアドバイザーのウェブサイトには、次のように記載されています。 全リージョンとインスタンスタイプにわたる中断の平均頻度は 5% 未満です。 私自身の使用状況から、私はインスタンスが数週間実行されることを確認しました。証明が必要ですか? これは、当社の本番環境クラスターの 1 つのインスタンスからのスクリーンショットです。 何日なのかが気になるとおっしゃるなら… はい、228 日間連続です。これと同じくらい長い時間は稼働しないかもしれませんが、スポットインスタンスが、通常、開始から 20 分以内に中断されるという誤った認識は否定できます。 スポットフリート スポットインスタンスでは、特定のアベイラビリティーゾーンにある特定のインスタンスに対して、単一のリクエストを行います。スポットフリートでは、単一のインスタンスタイプをリクエストする代わりに、要件を満たすさまざまなインスタンスタイプを要求できます。多くのワークロードでは、CPU と RAM が十分に近い限り、インスタンスタイプの多くでは順調に動作します。 そのため、スポットフリートを使用して、インスタンスタイプと複数のゾーンにインスタンスベットを分散させることができます。スポットフリートを使用すると、すでに述べたように中断率が低いことに加え、システムが劇的に堅牢になります。また、オンデマンドクラスターを実行して、追加の保護機能を提供することもできます。 ECS、スポットフリート: 素晴らしい組み合わせ スケーラブルなシステムを非常に低いコストで実現できるため、これはワークロードを実行するためのお気に入り方法の […]

Read More

[AWS Black Belt Online Seminar] Amazon EC2 資料及び QA 公開

先日 (2019/3/5) 開催しました AWS Black Belt Online Seminar「Amazon EC2」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190305 AWS Black Belt Online Seminar Amazon EC2 AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Nitro Hypervisor と KVMベースのハイパーバイザーとの違いは何でしょうか。今後はNitor Hypervisorベースが主になるのでしょうか。 A. Nitro Hypervisor はKVMのコアテクノロジーをベースとして構築されており、一般的なHypervisorの機能である、CPUやメモリの分離といった仮想化機能に加えて、Nitro CardなどEC2の専用ハードウェアコンポーネントを活用して、Hypervisorとしてより軽量に、仮想化インスタンスに対して一貫したパフォーマンスを提供できるように作られています。今後、新しいインスタンスタイプのほとんどがNitro Hypervisorを使用する予定です。Nitro Hypervisorに関しては、下記のFAQも参照ください。 https://aws.amazon.com/jp/ec2/faqs/#Nitro_Hypervisor Q. Public IPのユースケースがよくわかりませんでした。Public IPが変わっても、ALBの設定に連動するのでしょうか? A. EC2インスタンスをインターネットと通信する要件がある場合、1) VPCのサブネットにインターネットゲートウェイ(IGW)をアタッチする(このサブネットを「パブリックサブネット」と呼びます)のに加え、2) EC2インスタンスがインターネットから通信可能なIPアドレスを持つ必要があります。この2)を実現するひとつの方法がPublic IPアドレスです。Public IPアドレスを付与するかどうかはEC2インスタンス起動時のオプションで指定することができます。 後半のご質問は対象のEC2インスタンスがALBのバックエンドにアタッチされている場合、Public IPアドレスが変わったときどうなるか、というご質問としてお答えします。この場合、ALBに登録したインスタンスの設定を変更する必要はありません。これはALBはバックエンドEC2インスタンスをPublic IPアドレスの単位で管理しておらず、EC2インスタンスそのものとして管理しているためとお考えください。補足として、EC2インスタンスの稼働中にPublic IPアドレスは変更されることはなく、停止して起動するタイミングでのみ変更されます。このとき、インスタンスの停止中もALBからの登録状態は継続されます。 Q. Webサーバーなどのアプリケーション利用ではAMDのCPUは、有用性はありますでしょうか? A. 利用するアプリケーションの性能要件をAMDのCPUでも満たすことさえできれば、Intel版の同等のインスタンスタイプに比べてオンデマンド価格で10%程度安価にご利用頂くことが可能であり、コスト面でとても有用と思われます。 Q. 利用中のEC2で、armアーキテクチャのCPUに変更は可能ですか? A. 従来のx86とARMではCPUアーキテクチャが異なり、稼働するOSやアプリケーションもそれぞれのアーキテクチャに対応したものである必要があります。その為、利用中のEC2がx86アーキテクチャの場合は、インスタンスタイプの変更でARMアーキテクチャのA1インスタンスに変更するような事は行えません。OSからARMアーキテクチャのものを使用して構築して頂くことになります。 Q. Elastic […]

Read More

Portworx クラウドネイティブストレージを使用して、Amazon EKS で高可用性 Microsoft SQL Server コンテナを実行する

このブログ記事では、Amazon Elastic Container Service for Kubernetes (Amazon EKS) を使用したコンテナへの Microsoft SQL Server のデプロイについて説明します。ここで説明するものと同じアプローチと原則は、再利用可能で再現可能な DevOps プラクティスと組み合わせた高可用性 (HA) と耐久性を必要とする他のステートフルアプリケーションにも適用されます。ユースケースの例としては、MongoDB、Apache Cassandra、MySQL、ビッグデータ処理などがあります。 SQL Server をコンテナ内で実行するためのサポートは、SQL Server 2017 で初めて導入されました。Kubernetes (K8s と呼ばれることもあります) を使用して、Linux コンテナ内で本番用 SQL Server ワークロードを実行できます。 Microsoft SQL Server は、今日使用されている最も人気のあるデータベースエンジンの 1 つです。SQL Server は魅力的な機能と堅牢なコミュニティを数多く提供しますが、クラウドベースまたはオープンソースのデータベースソリューションよりもさらにメンテナンスを必要とするか、より高価です。組織によっては、オープンソースソリューションに移行してライセンスコストを削減することで、これらのコストを削減しようとしているところもあります。他の企業は、ワークロードを Amazon RDS for Microsoft SQL Server や Amazon Aurora などのマネージド型リレーショナルデータベース管理システム (RDBMS) サービスに移行することを選択しています。 ただし、組織が SQL Server エンジンから離れることができない […]

Read More

Amazon EC2 スポットインスタンスを使って GPU で深層学習モデルをトレーニング

ディープニューラルネットワークのアーキテクチャ向けに設計されたデータセットの収集と、トレーニングルーティンのコード化はすでに済んでいます。いつでも、最強の GPU インスタンスにある複数のエポックに、大規模なデータセットでのトレーニングを実行することが可能です。NVIDIA Tesla V100 GPU を搭載した Amazon EC2 P3 インスタンスが、計算集約型の深層学習トレーニングジョブに最適であることはわかりました。ただし、予算は限られており、トレーニングの費用を減らしたいと考えます。 スポットインスタンスの料金は、数時間から数日を要するトレーニングジョブを実行している深層学習の研究者や開発者のために、高性能 GPU を手頃で利用しやすいものにしています。スポットインスタンスを利用すると、オンデマンドレートよりも大幅に値引きされた価格で、予備の Amazon EC2 コンピューティング性能を利用できます。インスタンスおよびリージョンごとの最新の価格一覧については、スポットインスタンスアドバイザーをご覧ください。スポットインスタンスとオンデマンドインスタンスの主要な相違点の詳細については、Amazon EC2 ユーザーガイドをお読みいただくことをお勧めします。 スポットインスタンスは深層学習のワークフローに最適ですが、オンデマンドインスタンスと比べ、使用上の課題がいくつか存在します。まず、スポットインスタンスはプリエンプションが可能で、2 分前に通知すれば終了できます。これは、トレーニングジョブを実行し完了する際にインスタンスを当てにできない、ということを意味します。したがって、時間的制約のあるワークロードにはお勧めしません。第二に、トレーニングの進行状況が正常に保存されていなかった場合、インスタンスを終了したときにデータが紛失する可能性があります。第三に、スポットインスタンスを作成した後はアプリケーションを中断させないことを決定した場合、スポットインスタンスを停止し、オンデマンドインスタンスまたはリザーブドインスタンスとして再作成する以外に選択肢がなくなります。 これらの課題に対処するために、深層学習のトレーニングワークフロー向けにスポットインスタンスをセットアップし、同時に、スポットの中断が発生した場合にはトレーニングの進行状況の紛失を最小限に抑えることが可能な、ステップバイステップのガイドを用意しました。次の特徴を維持しながらセットアップを実装することが、ここでの目標です。 コンピューティング、ストレージ、コードのアーティファクトを分離し、コンピューティングインスタンスをステートレスに維持する。これにより、インスタンスが終了したときに、復旧とトレーニング状態の復元を簡単に行えるようになります。 データセット、トレーニングの進行状況 (チェックポイント)、ロゴのために、専用のボリュームを使用する。このボリュームは永続的で、インスタンスの終了の影響を受けるようなことがあってはなりません。 バージョン管理システム (例: Git) を使用する。このリポジトリは、トレーニングを開始/再開するためのクローンを作成する必要があります。これにより、トレーサビリティが有効になり、インスタンスが終了したときに変更されたコードが紛失することを防げます。 トレーニングスクリプトのコードの変更を最小限に抑える。これにより、トレーニングスクリプトを個別に開発することが可能になり、バックアップとスナップショットのオペレーションをトレーニングコードの外部で実行できます。 さまざまな自動化終了後の交換用インスタンスの作成、起動時のデータセットとチェックポイントのEBS ボリュームの添付、 アベイラビリティーゾーンを横断したボリュームの移動、インスタンスの状態の復元実行、トレーニングの再開、トレーニング完了後のインスタンスの終了、これらを自動化します。 TensorFlow と AWS 深層学習 AMI を使用したスポットインスタンスの深層学習 この例では、スポットインスタンスと AWS 深層学習 AMI を使って、CIFAR10 データセットで ResNet50 モデルをトレーニングします。 ここでは、AWS 深層学習 AMI バージョン 21 で入手可能な CUDA 9 を使って構成された、TensorFlow […]

Read More