Category: Compute

このブログ記事では、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 の一部についても共有しております。

我々はAmazon Connectによって強化されたコンタクトセンターを展開してきました。 あなたは今、顧客から電話で問い合わせを受けています。 素晴らしいことです。 ただし、迷惑電話が増えてきていることにも気付いています。 それはあまり素晴らしいことではありません。 このブログでは、発信者の番号に基づいてこの不要な着信通話の発信者を識別するソリューションを構築する方法をご紹介します。 着信を識別して対処するステップ まず、Amazon DynamoDBに電話番号のリストを作成し、Amazon Connectにすべての着信呼び出しについてこのリストをチェックさせます。 Amazon Connectがこのリストにアクセスするために、AWS LambdaをAmazon Connect問い合わせフローと統合します。 その後、すべての着信呼び出しに対してそのLambda関数を実行します。 AWS Lambdaは、着信呼び出しの番号についてデータベースを検索します。 一致したレコードが見つかった場合に問い合わせフロー内で別のパスへルーティングできるようにするために、AWS Lambdaはレコードの一致を示す値を返します。 このプロセスの4つのステップは以下のとおりです： Amazon DynamoDBにテーブルを作成する AWS Lambdaを使用して番号データベースを検索する 問い合わせフローでAWS Lambdaを使用するようにAmazon Connectを設定する Amazon Connectに返される値を確認する ステップ1：Amazon DynamoDBにテーブルを作成する Amazon DynamoDBコンソールを開きます。 テーブル作成を選択します。 [テーブル名]に、filteredNumbersと入力します。 プライマリキーにphoneNumberと入力します。 デフォルト設定を使用をチェックしたままにして、作成を選択します。 テーブルを作成したら、ブロックする電話番号を追加します。filteredNumbersを選択し、項目タブを選択し、「項目の作成」を選択します。 国際的に認められたE.164形式で電話番号を入力してください。 たとえば、北米の場合は+ 15551234567などです。 ブロックする番号を入力してから、保存を選択します。 ブロックするすべての番号について手順6を繰り返します。 注意 電話番号を入力するこれらの手順では、番号を個別に入力する必要があります。 電話番号をまとめて追加する方法については、DynamoDB CLIリファレンスを参照してください。 ステップ2：AWS Lambdaを使用して番号リストを検索する AWS Lambdaは、Amazon ConnectとAmazon DynamoDBテーブルをつなぐパイプの役割を果たします。 Amazon […]

本記事ではこれからAWS上でDockerコンテナを活用される方向けに、AWSのコンテナ関連サービスのどれを選択すると良いかの一例を紹介します。前提としては、example.com社の技術者Aさんが、自社のWebサービスをAWS上で構築するにあたって構成を決めるために、AWSのソリューションアーキテクト(SA)に相談するという流れの記事になります。AWSのどのサービスを使うかのご参考に是非ご覧ください。※こちらの選定はあくまで一例です。要件によっては選択すべきAWSのサービスが異なる点、予めご了承ください。

この投稿では、当社が受け継いできた関係データベース上に構築されたデータウェアハウスの代替としての、cloud-nativeデータウェアハウスの設計についてお話します。 設計過程のはじめで、最も簡単に見える単純なソリューションは、関係データベースから他のものへのリフト＆シフトマイグレーションです。しかし、当社は一歩戻り、まずはデータウェアハウスで何が本当に必要とされているかに焦点を当てることに決めました。当社はどのようにして、正しいツールを適した業務に使用することにより、従来のオラクルデータベースをより小さなマイクロサービスに分離できるかに着目し始めました。当社の方法はAWSツールを使用するだけではありませんでした。さらに、それはcloud-native技術を使用して当社を最終状態に持っていくためにマインドシフトすることでした。 このマイグレーションには既存データもマイグレートさせながら新規のデータを流入させるために、新規の抽出、変換、ロード(ETL)パイプラインが必要でした。このマイグレーションのため、AWS Glueに統合されることにより、当社は多くのサーバーを除去し、完全にサーバーレスのデータウェアハウスに移行することができました。 このブログ投稿で、当社は以下をご覧に入れます： 当社がデータウェアハウスのためにサーバーレスデータレイクを選択した理由。 Woot’sシステムのアーキテクチャー図。 マイグレーションプロジェクトの概要。 当社のマイグレーションの結果。 アーキテクチャーおよび設計の関係 こちらは当社が考慮した設計重点の一部です： 顧客体験。当社は常にお客様が必要とすることから始め、そこから戻るように業務を行いました。当社のデータウェアハウスは様々なレベルの技術専門性を持った人々による事業を渡って使用されます。 当社は異なるタイプのユーザーが運用の中に識見を持つ能力に焦点を当て、全体的な顧客体験を向上させるために、より良いフィードバックメカニズムを提供します。 最小限のインフラストラクチャーメンテナンス。「Wootデータウェアハウスチーム」は本当にたった一人の人です-Chaya! このため、当社がcloud-native技術を使用することができるAWSサービスに集中することは当社にとって重要です。これらは需要が変化し、技術が進化するにつれ、未分化性のインフラストラクチャーの管理といった困難な仕事を取り除きます。 データソースの変化に対する応答性。当社のデータウェアハウスは内部サービスの範囲からデータを取得します。弊社の既存のウェアハウスでは、これらのサービスへのいずれの更新でETL業務および諸表で手動による更新が必要でした。これらのデータソースのための応答時間は当社の主要関係者にとって重大なことです。このために当社は高性能アーキテクチャーの選択に向けたデータ主動のアプローチが必要でした。 生産システムからの分離。当社の生産システムへのアクセスは固く結びついています。複数のユーザーを許容するため、当社はそれを生産システムから分離し、複数のVPCsでのリソースをナビゲートすることの複雑さを最小化する必要がありました。 これらの要件に基づき、当社は運営面およびアーキテクチャーの面の両方で、データウェアハウスを変更することを決定しました。運営の観点から、当社はデータ摂取の目的で新規の共有応答モデルを設計しました。アーキテクチャーの面で、当社は従来の関係データベースに代わってサーバーレスモデルを選択しました。これら2つの決定は、当社がマイグレーションで行った、すべての設計および実装の決定を動かすこととなりました。 当社が共有応答性モデルに移行するにあたって、複数の重要な点が浮上しました。第一に、当社のデータ摂取の新しい方法はWootの技術組織にとっては主要な文化シフトでした。過去に、データ摂取は専らデータウェアハウスチームの担当で、サービスからデータを引っ張るためにカスタム化されたパイプラインが必要でした。当社は「押し、引かない」にシフトしました：サーバーがデータウェアハウスにデータを送信するべきである。 これが共有責任が行き着いたところでした。初めて、当社の開発チームがデータウェアハウスのサービスデータ全体の所有権を持ちました。しかし、当社は開発者にミニデータエンジニアになってほしくありませんでした。代わりに、当社はデータをプッシュするために、彼らに開発者の既存のスキルセットに適合する簡単な方法を示しました。データは当社のウェブサイトで使用される技術の範囲でアクセス可能である必要がありました。 これらの検討されたことは当社をサーバーレスデータウェアハウス向けの、以下のAWSサービスを選択することに導きました。 データ摂取用Amazon Kinesis Data Firehose データ保存用Amazon S3 データ処理用AWS Lambda および AWS Glue AWS データマイグレーションサービス (AWS DMS) および データマイグレーション用AWS Glue 統合およびメタデータ管理用AWS Glue クエリおよびデータ視覚化用 Amazon Athena および Amazon QuickSight 以下のデータグラムは当社がどのようにこれらのサービスを使用するかをハイレベルで示します。 トレードオフ これらの構成要素は共に当社のすべての要件を満たし、共有責任モデルを実行可能にしました。しかし、当社はリフト＆シフトマイグレーションをもう一つの関係データベースと比較し、数回のトレードオフを行いました。 最大のトレードオフは先行投資の努力対進行中のメンテナンスでした。当社はすべてのデータパイプラインをもって効果的に白紙の状態から開始し、新しい技術を当社のすべてのウェブサイトサービスに導入しました。これには複数のチームを渡り協力的な努力が必要となりました。最小限の現行メンテナンスは核心要件でした。当社が使用するサーバーレスコンポーネントの管理されたインフラストラクチャーの優位点を利用するために、当社は快くこのトレードオフを行いました。 もう一つのトレードオフは非技術ユーザー対ビッグデータテクノロジーを利用することの有用性のバランスを取ることでした。顧客体験を核心要件にすることは、当社がこれらのトレードオフを検討するときに、意思決定を導くのを助けました。最終的には、他の関係データベースへの切り替えは、当社のお客様が同じ体験をするだけで、より良い体験をするわけではなかったのです。 Kinesis Data Firehose および […]

このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。

AWS Systems Manager Automation は AWS リソースを集中管理するためにマルチアカウントおよびマルチリージョンを対象としたアクションを実行することができます。この機能を活用することでアカウント全体への設定の適用、運用アクション、コンプライアンス管理、に必要な時間とオーバーヘッドを減らすことができます。 このブログ記事では、AWS Systems Manager Automation を使用して、マルチアカウントおよびマルチリージョン環境のマネージドインスタンスにパッチを適用する方法を紹介します。またパッチ適用のために、インスタンス管理にどのようにリソースグループを活用するか説明します。例えば、開発、テスト、および本番などのさまざまな環境用のリソースグループを作成できます。そして Patch Manager を活用したカスタム自動化ドキュメントの作成方法と、カスタム自動化ドキュメントを実行してマネージドインスタンスにパッチを適用する方法を説明します。

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。