Category: Compute

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

先日 (2019/4/17) 開催しました AWS Black Belt Online Seminar「Amazon VPC Advanced」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190417 AWS Black Belt Online Seminar Amazon VPC Advanced from Amazon Web Services Japan 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 での共有の有効化」を参照してください。 […]

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/エンジニアリングマネージャー 藤井洋太郎氏

「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開発チーム 福本江梨奈氏

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、スポットフリート: 素晴らしい組み合わせ スケーラブルなシステムを非常に低いコストで実現できるため、これはワークロードを実行するためのお気に入り方法の […]

先日 (2019/3/5) 開催しました AWS Black Belt Online Seminar「Amazon EC2」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190305 AWS Black Belt Online Seminar Amazon EC2 from Amazon Web Services Japan 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%程度安価にご利用頂くことが可能であり、コスト面でとても有用と思われます。 […]

このブログ記事では、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 エンジンから離れることができない […]

ディープニューラルネットワークのアーキテクチャ向けに設計されたデータセットの収集と、トレーニングルーティンのコード化はすでに済んでいます。いつでも、最強の 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 […]

Amazon Connectで作るセキュアなIVRソリューション Amazon Connectの問い合わせフローを使用して、ダイナミックな自動音声応答（IVR）ソリューションを作成できます。 Amazon Connectを使用すると、適切に個人情報を収集し、IVRによる顧客体験をカスタマイズすることができます。 個人情報として、社会保障番号、クレジットカード情報、および住所などが考えられます。 コンプライアンス上の理由から、個人情報など機密性の高い情報は通信時および保管時に暗号化する必要があります。 常に個人情報は暗号化しましょう。 このブログでは、Amazon Connectの[顧客の入力を保存する]ブロックを使用して機密な個人情報を収集し、ご自身でお持ちの暗号化キーを使用してデータを自動的に暗号化する方法について説明します。 この機能により、暗号化の要求に応えることができます。 この目的のために、Amazon ConnectはAWS Encryption SDKを使用して顧客提供データを暗号化します。 SDKはエンベロープ暗号化アプローチを使用します。 これにより、生データとそれらの暗号化に使用されるデータキーの両方が保護されます。 AWS Encryption SDKの機能の詳細については、Envelope Encryptionを参照してください。 この記事では、以下の手順を説明しています。 クレジットカード番号を収集するようにAmazon Connectを設定します。 クレジットカードの番号を暗号化します。 ご自身でお持ちの復号化キーを使って復号化するために、バックエンドのAWS Lambdaに暗号化されたクレジットカード番号を送信します。 次の図に示すAmazon Connect問い合わせフローを使用します。 セキュアなIVRの作成 このセキュアなIVRを作るために、以下を実施する必要があります。 新しい暗号化キーと復号化キーを作成するか、既存のものをインポートします。 復号化キーをAWSパラメータストアに安全に保存する 収集した番号を復号化するためのAWS Lambda関数を作成します。 収集したクレジットカード番号を暗号化するために、Amazon Connectに公開鍵をアップロードします。 前のセクションで説明した問い合わせフローを作成します。 注意 セキュアなIVRを作るために、AWS Command Line Interface（AWS CLI）がインストールされ、セットアップされ、Amazon Connectインスタンスと同じリージョンに設定されていることを確認しましょう。 ターミナルウィンドウから“ aws configure”を実行できることを確認し、デフォルトのリージョンパラメータに正しい値が設定されていることを確認します。 Amazon Connectの顧客入力を暗号化する機能は、ご自身でお持ちの公開鍵を使用してデータを暗号化するように設計されています。 これにより、自分の秘密鍵を使用してデータを復号化し、データを後続処理に利用できます。 顧客だけが知っている秘密鍵を使用すると、要求されるプライバシーを保護するのに役立ちます。 既存の鍵ペアを使用することも、新しい鍵ペアを作成することもできます。 鍵情報が利用可能であるかぎり、このプロセスは変わりません。 […]

先日 (2019/3/13) 開催しました AWS Black Belt Online Seminar「Amazon VPC Basic」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。