Amazon Web Services ブログ

利用可能になりました – Amazon Linux AMI 2017.09

Amazon Linux AMI の最新バージョン (2017.09) が、すべての AWS リージョンの現行世代の EC2 インスタンスで利用可能になったことをお知らせします。AMI には、EC2 上で実行するアプリケーションのために安定した安全で高性能な環境を提供するように設計された Linux イメージのサポートと保持が含まれています。

簡単なアップグレード
次の 2 つのコマンドを実行して既存のインスタンスをアップグレードし、再起動します。

$ sudo yum clean all
$ sudo yum update

盛りだくさん
AMI には多くの新機能が含まれており、そのうち多くはお客様のリクエストに応えて追加されたものです。概要は次をご覧ください。

Kernel 4.9.51 – Based on the 4.9 の安定したカーネルシリーズをベースにしたこのカーネルには、ENA 1.3.0 ドライバーと TCP Bottleneck Bandwidth and RTT (BBR) のサポートが含まれています。私の投稿 Elastic Network Adapter – High-Performance Network Interface for Amazon EC2 to learn more about ENA をお読みください。BBR を有効にする方法については、リリースノートをお読みください。

Amazon SSM Agent – Amazon SSM Agent がデフォルトでインストールされるようになりました。これにより、EC2 Run Command を使用して、追加セットアップを必要とせずにインスタンスでスクリプトを設定して実行できるようになりました。詳細については、Systems Manager Run Command を使用したコマンドの実行または Manage Instances at Scale Without SSH Access Using EC2 Run Command をお読みください。

Python 3.6 – 最新バージョンの Python が含まれ、virtualenv および alternatives で管理できるようになりました。Python 3.6 は次のようにインストールできます。

$ sudo yum install python36 python36-virtualenv python36-pip

Ruby 2.4 – 2.4 シリーズの最新バージョン Ruby が利用可能になりました。次のようにインストールします。

$ sudo yum install ruby24

OpenSSL – AMI は、OpenSSL 1.0.2k を使用するようになりました。

HTTP/2 – HTTP/2 プロトコルが AMI の httpd24nginx、および curl パッケージでサポートされるようになりました。

リレーショナルデータベースPostgres 9.6 および MySQL 5.7 が利用可能になりました。次のようにインストールできます。

$ sudo yum install postgresql96
$ sudo yum install mysql57

OpenMPIOpenMPI パッケージが 1.6.4 から 2.1.1 に更新されました。OpenMPI 互換パッケージが利用可能になり、古い OpenMPI アプリケーションの構築と実行に使用できるようになりました。

その他 – その他の更新パッケージには、Squid 3.5Nginx 1.12Tomcat 8.5、および GCC 6.4 があります。

今すぐ起動できます
この AMI を使用して今すぐすべての AWS リージョンで EC2 インスタンスを起動できます。この機能は、EBS-backed インスタンスと Instance Store-backed インスタンスで使用でき、HVM および PV モードをサポートします。

Jeff;

Step Functions を使用するともっとうまくできます

私はよく Amazon のイノベーション文化についてプレゼンテーションを行いますが、Amazon の創設者 Jeff Bezos の意義深い引用を取り上げたスライドから始めることが多くあります。

お客様にお会いして、私たちがお客様の創造性や夢の追及をどのように支援できているかについて知るのは楽しいものです。今年に入って、Coca-Cola Company の Patrick と歓談し、AWS Step Functions や他の AWS のサービスを使用して Coke.com の Vending Pass プログラムをサポートした方法を教えてもらいました。このプログラムでは、Coca-Cola Vending Pass を使用したモバイル支払いをサポートしている自動販売機で製品を購入することで、ドリンクがプレゼントされます。参加者が NFC 対応電話をスワイプすると Apple Pay または Android Pay で購入が完了し、自動販売機で個人が識別されてクレジットを獲得できます。このクレジットを貯めることで、将来自販機で無料で購入できます。

スワイプ後、SNS トピックと AWS Lambda 関数の組み合わせにより既存のバックエンドコードに対する 1 組の呼び出しが開始され、販売ポイントがカウントされて参加者の記録が更新されます。残念ながらバックエンドコードは反応が鈍く多少のタイミング依存性があり、更新が行われず Vending Pass 利用者が混乱する可能性がありました。この問題に対する初期のソリューションは非常にシンプルでした。Lambda コードを変更して 2 つの呼び出しの間に 90 秒間のディレイを含めたのです。これにより問題は解決しましたが、処理時間がかかるのはいいことではありませんでした (Lambda 関数の使用料金は 100 ms 間隔のリクエスト所要時間に基づいています)。

ソリューションの費用対効果を向上させるため、チームは AWS Step Functions に注目し、非常にシンプルなステートマシンを構築しました。以前のブログ投稿で書いたように、Step Functions により、簡単に構築できる視覚的なワークフローを使用して分散アプリケーションとマイクロサービスのコンポーネントを大規模に調整できます。

Coke は非常にシンプルなステートマシンを構築して、ビジネスロジックを簡易化し、コストを削減しました。他のお客様も同様に簡易化できるはずです。またはシーケンシャルおよびパラレル実行や、代替ステートを使用する判断や選択を行う機能など、他のステップ関数機能を利用することもできます。Coke のステートマシンは次のようなものです。

FirstState および SecondState の各ステート (Task ステート) は該当する Lambda 関数を呼び出し、その間に Step Functions は 90 秒のディレイ (Wait ステート) を設けます。この変更によりロジックが簡易化されコストを削減できました。このすべての構成を以下に示します。

次のステップ
この最初の成功により、彼らはサーバーレスコンピューティングにより注目し、他のプロジェクトでの使用を検討しました。Patrick の話では、すでに生産性の飛躍的な向上と見られ、また開発者は喜んでいるそうです。開発者はサーバーがプロビジョニングされるのを待つ必要がなくなり、(Jeff が言うように) 創造性を解き放ち夢を追求できるようになりました。彼らは Coca-Cola Vending Pass での初使用例を大きく超えて、Step Functions を使用して自分たちのアプリケーションのスケーラビリティ、機能性、信頼性を改善するつもりです。たとえば、Coke は Lambda、Step Functions、および API Gateway を使用して、食品サービスパートナーに栄養情報を発行するサーバーレスソリューションを構築済みです。

Patrick のチームは現在、マシンラーニングと人工知能を使用した実験を行っています。彼らは、Instagram に掲載される写真のストリームを分析し、味やフレーバーのトレンドを抽出するプロトタイプアプリケーションを構築しました。このアプリケーション (簡易的なワンデープロトタイプとして構築) は LambdaAmazon DynamoDBAmazon API Gateway、および Amazon Rekognition を利用しており、Patrick の言葉によると、「大成功であり可能性のかたまり」だそうです。

サーバーレスアプリケーションをさらにすばやく構築するために、開発チームでは Serverless Application Framework 上に構築された内部 CI/CD リファレンスアーキテクチャを作成しました。このアーキテクチャには、内部サービスおよびアセットにアクセスするための Serverless のガイド付きツアーおよびいくつかのボイラープレートコードが含まれています。このモデルによって、有望なプロジェクトを「個人とコンピュータ 1 台」から開発チーム全体に簡単に拡大できると Patrick は言っていました。

Patrick は AWS re:Invent で私の同僚 Tim Bray の次に登壇予定です。ぜひ SRV306 – State Machines in the Wild! How Customers Use AWS Step Functions に参加して彼らに会ってください。

Jeff;

Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ

本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。

Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見することがあります。これは問題になっているコードの変更を探すことを困難にし、不必要なストレージ料金も引き起こします。以前は、レポジトリをクリーンアップするには、手動で古いイメージを削除するのに時間を費やしたり、スクリプトを書いて実行する必要がありました。

今日からライフサイクルポリシーを使うことで、古いコンテナイメージを自動的に削除するためのいくつかのルールを定義することが可能になりました。ルールが実行された時に影響を受けるコンテナイメージを実際にプレビューで確認することも可能です。これによって、レポジトリはより組織化され問題になっているコードのリビジョンを簡単に見つけられ、そしてストレージコストも抑えられます。

それでは、ライフサイクルポリシーがどのように動くかを見てみましょう。

基本的なルール

コンテナを使ってコードをデプロイすることの最も大きい利点の1つは、素早く簡単に過去のバージョンにロールバックできるということです。これにより、リスクを抑えてデプロイすることが可能になります。なぜならば、もし何かおかしかったら、過去のコンテナのバージョンに戻して、失敗したデプロイ以前の状態でアプリケーションを動作させることが簡単にできるからです。多くの人は、数個前のバージョンにロールバックするということはおそらくしないでしょう。もしこういった状況であれば、1つのシンプルなライフサイクルルールとしては、最新の30イメージを保持するというものが考えられます。

最新の30イメージ

ECRレジストリの中から、Dry-Run Lifecycle Rules, Addを選択します。

  • Image Statusには、Untaggedを選択します。
  • Match criteriaでは、Count TypeImage Count More Thanを入力します。
  • Count Numberには30を入力します。
  • Rule actionにはexpireを選択します。

Saveを選択します。どのイメージがクリーンアップされるかを見るには、Save and dry-run rulesを選択します。

もちろん、数による保持ではなく、コンプライアンスの理由で期限によっていくつかのイメージを保持したいチームも存在します。そういった場合には、90日以前のイメージをクリーンアップするという選択もできます。

最新90日分

先程作成したルールを選択し、Editを選びます。パラメータを変更して、タグがついていないイメージを90日だけ保持する様に変更します:

  • Match criteriaでは、Count TypeSince Image Pushedを入力します。
  • Count Numberには90を入力します。
  • Count Unitにはdaysを選択します。

タグ

もちろん90日というのは任意の時間に設定できますが、ある特定の種類のイメージだけもっと長い期間保持するようなポリシーが必要なこともあります。そういった場合で、でも大掃除は続けたいというときには、タグがつけられたイメージだけ削除するというのを検討することも可能です。

こちらのルールのリストは、タグが無いもの、development、staging、そしてproductionなイメージへのルールの例をまとめてみたものです:

  • タグのないイメージは90日以前を削除
  • developmentタグのついたイメージは90日以前を削除
  • stagingタグのついたイメージは180日以前を削除
  • productionタグのついたイメージは1年以前を削除

ご覧頂いた通り、新しいAmazon ECRのライフサイクルポリシーは強力で、必要なイメージだけを保持するのが簡単になり、もう必要のないイメージをクリーンアップしてくれます。この機能は本日よりAmazon ECRが利用可能な全てのリージョンで、追加コスト無しに利用可能です。より詳しい情報は、AWSの技術ドキュメントの中のAmazon ECR Lifecycle Policiesをご覧ください。

— Brent
@brentContained

原文: Clean up Your Container Images with Amazon ECR Lifecycle Policies (翻訳: SA岩永)

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。

もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。

TLS? SSL? SNI?

SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。

TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。

SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。

フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。

ALBの証明書スマートセレクション

ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択肢、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。

ALBでSNIを利用する

ここではウェブサイトの例として、VimIsBetterThanEmacs.comVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。

最初に、コンソールから私のロードバランサを選択肢、listenerタブに行き、”view/edit cerfiticates”を選択します。

次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。

これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。

aws elbv2 add-listener-certificates --listener-arn <listener-arn> --certificates CertificateArn=<cert-arn>

知っておくべきこと

  • ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。
  • ACMかIAMにある全ての証明書を利用することができます。
  • 同一ドメイン向けの複数の証明書を1つのsecure listenerに紐付けることができます。ALBはクライアントのサポート範囲を含む複数の因子を元に適切な証明書を選択します。
  • もしクライアントがSNIをサポートしていない時には、ALBは(listener作成時に1つ指定する)デフォルト証明書を使います。
  • 3つの新しいELB API呼び出しが追加されます: AddListenerCertificates, RemoveListenerCertificates, そしてDescribeListenerCertificatesです。
  • (デフォルト証明書を除いて) ロードバランサ毎に最大25個の証明書を紐付け可能です。
  • リリース時点でこれらの新しい機能はAWS CloudFormationでサポートされています。

私の同僚のJon Zobristが作ったウェブサイトでこれらの新しい機能が稼働している例を見ることができます: https://www.exampleloadbalancer.com/.

全体を通して、私は個人的にこの機能を使っていきますし、多くのAWS利用者もこのメリットを受けることができると確信しています。Elastic Load Balancingチームには、これを我々のユーザに届けるためのハードワークをしてくれたことに感謝したいと思います。

Randall

原文: Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI (翻訳: SA岩永)

11 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー11月の配信についてご案内させて頂きます。初めてご紹介するNLB (Network Load Balancer) を中心としたELBのセッションをはじめ、今月も様々なテーマを取り扱います。

また今年もAWS re:Inventの開催期間中に現地からの生中継で最新アップデートをお伝えする回を予定しておりますので、こちらもぜひご登録いただければと思います。

 

 

 

 

 

 

 

 

 

11月の開催予定

サービスカット
11/1(水) 18:00-19:00 Amazon EMR
11/15(水) 18:00-19:00 ELB Update – Network Load Balancer(NLB)と関連サービス
11/22(水) 18:00-19:00 AWS WAF – OWASP Top10脆弱性緩和策 –

ソリューションカット
11/9(木) 12:00-13:00 Amazon Pinpoint で始めるモバイルアプリのグロースハック  ※ 通常の開催曜日と異なりますのでご注意ください
11/21(火) 12:00-13:00 AWS上の位置情報
12/1(金) 12:00-13:00 AWS re:Invent 2017 Report  ※ 通常の開催曜日と異なりますのでご注意ください。また12月開催ですが先行告知させて頂きます

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。

 

Lumberyard Beta 1.11-Flow GraphとCryAnimationにお別れを…全く新しいビジュアルスクリプティングとアニメーションツールに

つい先日までのLumberyardとは違います。もし、しばらく離れられていたなら新しいLumberyardを見ていただく良い機会です。

新たなビジュアルスクリプティングとアニメーションツールが実装された Lumberyard 1.11を こちら からダウンロードできます。

これまでの19ヶ月で オリジナルのコードベースの60%を入れ替えており、3,300以上の改善と、500個の無料アセットを追加し、皆さんゲームプロジェクトでご利用いただけるようになりましが、今回のリリースはエンジンと皆さんの制作体験上とても重要なターニングポイントになります。なぜなら…

  1. 新アニメーションシステムとしてEMotion FXが導入され、CryAnimation (GeppettoとMannequin)と置き換えられました。エンジニア不在でも、ブレンドツリー、ステートマシン、ブレンドスペース、モーションツリー等の機能を使って10分程触っていただくだけで高品質なアニメーションを制作できます。EMotion FX はこれまでにEAやUbisoftのようなスタジオで10年以上に渡って利用されてきていましたが、今回Lumberyardの永続的なパートとなり、強力かつ扱い易いソリューションをアーティストの皆さんに提供できることになました。(1.11の新たなサンプル中に我々のキャラクターRinがありますのでお試しください。サンプルへのアクセス方法は こちら)
  2. Script Canvasが、これまでのFlow Graphと置き換えられ、新たなビジュアルスクリプティングソリューションになりました。Script CanvasでLuaやC++と同様にゲーム内の挙動をオーサリングできるソリューションとなります。これにより、必要とされるエンジニアがいない場合でもEMotion FXで作成されたクールなアニメーションをScript Canvasで即座にキャラクターの挙動を制作できるということになります。プログラミング経験に乏しくても、Script Canvasのノードインターフェースで、品質の高いゲームプレイ体験を創り出していただけるようになります。Script Canvasで皆さんの創り出されるものを楽しみにしています。(Script Canvasの開始方法やチュートリアルは こちら の最新ドキュメントをご参照ください)
  3. さらに新たに、将来を見据え CryEntity コンバートツールを用意し、CryEntityを新たなComponent Entityフォーマットにコンバートできるようにしました。これにより、将来Lumberyardの新たな上システムの利点を享受し安定した土台の上にゲームを構築できるようになります。まだまだ沢山の作業がありますが、素晴らしい開発コミュニティの皆さんと共に進化と成長を続け育てていくことはとてもエキサイティングなことです。 (コンバートツールのご利用は こちらのチュートリアルをご参照ください)

 

EMotion FX

 

Script Canvas

400以上の追加アップデート

今回のリリースには沢山の更新がありますので詳しくは こちら をご参照ください。

  • 新たに3つのCloud Gemが加わり、ゲーム中のプレイヤーの状態を簡単に観測したり、 Amazon Polly を活用したSpeech Gemでテキストを読ませたり、Amazon Lex による音声認識をゲームプレイで活用したりできるようになりました。
  • 新規プロジェクトのスタート地点として、新たに2つのプロジェクトテンプレートが加わり、デフォルトのテンプレートはGem群を有効にしてシンプルなレベルからのスタートとして、空のテンプレートは最低限の素の状態のテンプレートとなります。
  • 新たなGetting Started Guide(初心者ガイド)により、以前よりもさらに素早くLumberyardを始めていただけるようになりました – 迷路脱出ゲームをお友達と簡単にシェアできてしまいます。ドキュメントは こちら になりますが、新たなビデオシリーズもご期待ください。
  • 新たに実験的に実装されたトゥーンシェーダーでゲームの見栄えをがらっと変えていただくことも可能です。Starter Gameを読み込んでコンソールコマンド「r_ApplyToonShading = 1」でお試しいただけます。shadeLib.cfi内がリファインされる可能性があります。
  • さらに沢山のユーザビリティ向上へのフィードバックをありがとうございました。アウトライナとアセットブラウザ上でのドラッグアンドドロップによる並べ替えのサポート、ゲーム起動時の1クリックでのエンティのアクティベート、独自のコンポーネントを作成された場合にURLを関連付けチーム作業効率を高める事もできます。

 

みなさんのご意見をお聞かせください。
前回もお伝えしたように、皆様からのフィードバックは我々のロードマップ形成に欠かせませんので、今後ともよろしくお願いいたします。Lumberyardについて深くお知りになりたい場合は チュートリアルコミュニティーフォーラムドキュメント も既にありますのでぜひご覧ください。

翻訳は下田が担当しました。原文はこちら

大規模なデータベースをオープンソースデータベースへ移行する際のカテゴリ分けと優先度づけ

AWS Schema Conversion Tool (AWS SCT)AWS Database Migration Service (AWS DMS) はコマーシャルデータベースからAmazon RDSの様々なデータベースエンジンへの移行を簡単に行えるようにするツールです。 AWS SCTはプロプライエタリなデータベースをオープンソースデータベースへ移行する際に手助けを行います。移行元のデータベーススキーマや多くのカスタムコードを移行先のデータベースに適した形へ変換を行います。ツールが変換を行うカスタムコードには、ビュー、ストアード・プロシージャー、ストアード・ファンクションを含みます。一方、自動的に変換が出来ないものとしては、手動で変換が行いやすいように該当箇所を抽出します。AWS DMSはダウンタイムを最小限に抑えながら、簡単・安全にデータを移行することを可能にします。

データベースエンジンを変更することは大変な作業ですが、Amazon Auroraのようなスケーラブルでコスト効率がいいフルマネージドサービスの恩恵を受けやすくなる利点があり、移行を行う価値があります。AWS SCTとAWS DMSを用いることで、単一のデータベースからオープンソースへの移行を評価し、計画を行うことが容易になります。 AWT SCTアセスメントレポートを生成し、これらのツールを使用することで、データベースを移行することが、どのくらい簡単であるかということがおわかりになると思います。

以下のブログやビデオは、オープンソースデータベースへ移行するための情報の一例です。

もし、数百・数千のデータベースを持っていた場合は
評価レポートを作成し、1つ、2つ、またはさらに10のデータベースをオープンソースデータベースへ移行することは、簡単なプロセスです。 おそらく、どのアプリケーションが利用しているデータベースを最初に移動するか判断するための材料は十分お持ちだと思います。 組織内外で利用されている数百または数千のデータベースインスタンスがあり、十分なアプリケーションの知識がない場合はどうなるでしょうか?

集中管理されたIT部門では、管理するデータベースの数、バックアップのスケジュール設定などを一元管理することが出来ます。 しかし、大規模な動向を計画したり、分析のために優先順位を付けるための十分な詳細がないかもしれません。 この記事では、データベースポートフォリオを評価し、管理可能な移行のパイプラインに分解してプロセスを円滑に進めるための方法について説明します。

小さいプロジェクトのコラボレーション

1つの異種データベース移行の詳細なプロジェクト計画は、次の表に示すように12の手順で構成されます。

フェーズ 説明 フェーズ 説明
1 評価 7 システム全体で機能テスト
2 データベーススキーマ変換 8 パフォーマンステスト
3 アプリケーション変換/修正 9 結合とデプロイ
4 スクリプト変換 10 トレーニング
5 サードパーティアプリケーションとのインテグレーション 11 ドキュメントと変更管理
6 データ移行 12 リリース後のサポート

このブログの目的上、移行プロジェクトを計画するプロセスは、分析と計画、スキーマ移行、データ移行、アプリケーション移行、およびカットオーバーの5つの作業領域に分類できます。 移行の所要時間は、通常、移行およびテストのフェーズでどのくらいの時間を費やすかによって異なります。 いくつかの移行を並行して計画している場合は、どちらの移行が最も時間がかかるのか、最初に取り組むことができるのか、迅速に取り組むことができるのかを理解する必要があります。

CTWorkflow

オープンソースデータベースに移行する際に最初に分析するデータベースの優先順位付けは、データベース内で独自のコードがどれくらい使用されているかに左右されます。 使用しているプロプライエタリコードの量は、プロジェクトの移行段階でそれを変換してテストするのにかかる時間に影響します。 カテゴリーと基準を設定した後に、ディクショナリクエリを使用してデータベースをワークロード別に分類できます。

ワークロードを分類するためのフレームワーク

ワークロードは、通常、さらに分析するために5つのカテゴリに分類されます。 このブログでは、カテゴリ1〜3に焦点を当てます。

カテゴリ 1: (ODBC/JDBC)

ODBC(Open Database Connectivity)/ JDBC(Java Database Connectivity)を使用するアプリケーションは、 プロシージャ、ファンクション、トリガー、またはビューで独自のデータベースコードの利用量はとても少ないです。 アプリケーションロジックは、データベース外のコード(例えば、Java、Python、Ruby)にあるため簡単に別のデータベースに移行できます。

カテゴリ2: (独自データベースコードが少ないワークロード)

これらのワークロードでは、アプリケーションレベルのコード(Java、Python、Ruby、bashなど)と独自のデータベースコードを組み合わせて、JavaやPythonで扱いにくい機能を実行します。 経験則として、200未満のプロシージャ/ファンクションがこのカテゴリに分類されます。 高度な機能を使用する場合の許容範囲はさまざまです。 高度な機能を使用すると、ターゲットエンジンへのコードの自動変換が遅くなる可能性があります。 これらのワークロードでは、通常スキーマ設計はかなり簡単です。 テーブルやビューのような基本的なデータ構造を使用します。

カテゴリ3: (独自データベースコードが多いワークロード)

これらのワークロードは、独自のデータベースコードによって完全に実行され、多くの場合、高度な機能が使用されます。 これらのワークロードの多くは、1,000以上の独自の機能を備えています。 また、機能列、マテリアライズド・ビュー、リンクされたサーバーなどの高度なスキーマ機能も使用します。これらのワークロードの課題は、他のフレームワークに変換する際にに多くの作業時間を必要とすることです。 ソースコードで実行されるチューニングオプションは、変換しターゲットエンジンでテストを行う必要があるためです。

カテゴリ4: (ベンダ依存のワークロード)

これらのワークロードは、限定された商用エンジンのサポートのみで動作するフレームワークを使用します。 これらのワークロードをオープンソースに移行することは、アプリケーションを完全に再設計するか、現在サポートされていない高度な機能を必要とします。 機能は移行が非常に難しく、非常に多くの作業時間を消費します。

カテゴリ5: (レガシーワークロード)

これらのワークロードは独自のプログラミングインターフェイスを使用してプログラムを実行します。 例として、Oracle OCIアプリケーションなどが含まれます。 これらは従来のワークロードであることが多く、顧客はこれらのプログラムのソースコードを持っていない可能性があります。 めったに移行されることはありません。

ワークロードの優先度付け

データベースのインベントリを中央のリポジトリに保存しておくと、SQLやスクリプティング言語のような手持ちのツールを使用してポートフォリオ評価を自動化できます。

Oracle

Oracleデータベースの利用が多い場合は、PL / SQLブロックを使用してデータベース内のスキーマをループし、SELECT ANY DICTIONARYが付与されたユーザーに提供される情報を抽出できます。 SQL * Plusを使用し、不要なシステム・スキーマを除外し、コンマで区切られた値のセットをローカル・ファイルmigration_candidates.csvに追加します。 複数のデータベースに適用するには、bashスクリプトまたはプログラムを使用してインベントリシステムまたはファイルから読み込み、スクリプトを繰り返し実行し、同一ファイルに書き込みます。 こちらリポジトリーからOracle用のサンプル・スクリプトをダウンロードできます。

SQL Server
SQL Serverデータベースの利用が多い場合は、SQLブロックを使用してデータベースから読み取り、MSDBおよびsysスキーマから選択する権限を持つユーザーに提供される情報を抽出できます。 SQL Serverデータベースに対してsqlcmdを使用してスクリプトを実行し、コンマ区切りの結果を取得して、ファイルシステムのローカルファイル(migration_candidates.csvなど)に書き込むことができます。 複数のデータベースに適用するには、PowerShellスクリプトまたはプログラムを使用してインベントリシステム、またはファイルから読み取り、同一ファイルに追加するスクリプトを繰り返し実行します。 こちらのリポジトリからSQL Serverのサンプルスクリプトをダウンロードできます。

スクリプトの出力のレビューとカテゴリー分け

すべてのデータベースから結果を取得したら、その結果をMicrosoft Excelまたは別のツールにロードして、データ内のパターンを探します。 次の例では、条件付きデータバーは、ワークロードを分類する際に検討する必要がある度合いを示します。 こちらのリポジトリからサンプルワークロードワークシートをダウンロードできます。

Reviewing-and-categorizing-script-output

カテゴリ 1

緑で強調表示されたいくつかのワークロードがカテゴリ1と見なされ、分析および移行のためにチームに割り当てる必要があります。 これらのワークロードには、移行が必要なコードオブジェクトがほとんどなく、独自の機能(リンクされたサーバー、ジョブ、索引ビューなど)をほとんど使用しないか、または使用しない単純なスキーマ(たとえば、表やビューの数が少ない)があります。

カテゴリ 2

前述のワークロード例では、黄色で強調表示されているカテゴリ2のワークロードがいくつかあることがわかります。これらのデータベースには、少なくともテストを行うために移行フェーズを延長する可能性のある、かなり多くのプロシージャーや多くの独自機能の利用があります。

カテゴリ 3

ワークロード例の1行目〜4行目には、カテゴリ3に分類されるオレンジ色のワークロードが表示されています。これらのデータベースは1,000以上のプロシージャーとファンクションがあり、複雑な構造とジョブやリンクサーバーなどの高度な機能を持っています。

チーム毎の課題

移行パイプラインの概要を確認したので、チームが作業にどのように取り組むか計画をすることができます。 次の例でチームAは、カテゴリ1の移行に重点を置いています。 彼らは迅速に幾つかの移行を完了、パイプラインを次々と移動させます。 チームBは、移行フェーズでは追加の時間を費やす必要があるカテゴリ2の移行を行い、チームCは、同じ時間枠でより複雑なカテゴリ3の移行の内1つを行うことになります。

各マイグレーションは、分析とスキーマ、データ、およびカットオーバーのためのアプリケーションの移行の計画までのすべての移行フェーズを実行します。 しかし、各チームは必要な作業量に基づいて異なるペースで動きます。

TeamComparison

まず、カテゴリ1の移行を対象にすることで、そこで学んだことを後のプロジェクトにすぐに反映させることができます。 大規模なプロジェクトを開始する場合は、拡大したプロジェクトに取り組む前に、チームに勢いを与えることになります。 すべてのプロジェクトを追跡し、作業のパイプラインを維持することで、チームの関与が維持され、全体の進捗状況に関連したステータスを把握することができます。 全体的な結果は、通常、プロジェクトの利害関係者にとって最大の関心事です。 こちらのリポジトリからサンプル計画シートをダウンロードできます。

まとめ

1つの作業としてオープンソースエンジンへの全体的な移行を見ると非常に難しい作業に感じるかもしれません。 作業を最初のハイレベルな評価段階で管理可能サイズに細分化し、最初に速移行可能な物をターゲットにし、全体的なステータスを報告することで、移行の作業パイプラインを管理しし、チームを時間通もしくは早期に作業を完了させることに集中させることができます。


About the Author

Wendy Neu has worked as a Data Architect with Amazon since January 2015. Prior to joining Amazon, she worked as a consultant in Cincinnati, OH helping customers integrate and manage their data from different unrelated data sources.

 

 

翻訳は星野が担当しました。原文はこちら

Amazon Lex と Amazon Alexa を使用した質疑応答ボットの作成

ユーザーの質問に対する回答を持っていますが、ユーザーが質問をして適切な回答を得る良い方法が必要です。多くの場合、ユーザーはヘルプデスクに電話するか、サポートフォーラムに投稿しますが、ストレスが高まり、組織にとってコストがかかります。チャットボットがあれば、顧客にとって便利でしょう。興味深いことに、最近の調査は、ユーザーの 44% が人間と話すよりもチャットボットと話すことを望んでいます。

この投稿では、QnABot (「キューアンドエーボット」と発音) と呼ばれるサンプルソリューションについて説明します。 QnABot は、Amazon LexAmazon Alexa を使用して、「質疑応答」のための便利なインターフェイスを提供します。これにより、ユーザーは質問をして関連する回答をすばやく得ることができるようになります。

Amazon Lex を使用すると、音声とテキストチャットアクセスの両方を既存のアプリケーションに統合できます。Amazon Alexa を使用すると、Amazon Echo または Alexa Voice Service 対応デバイスを自宅や職場で使用しているユーザーに、ハンズフリー音声インターフェイスを提供できます。QnABot は両方の長所を最大限に活用しています。

QnABot は、Amazon Elasticsearch Service (Amazon ES) を使用して質問と回答を検索可能にします。ユーザーが質問をすると、Amazon ES の強力な全文検索エンジンが背後で使用され、その質問に最も合った回答が検索されます。

以下のセクションでは、次のことを行う方法について説明します。

  • QnABot を AWS アカウントにデプロイする。このブログでは、お客様が既に AWS を利用していることを前提としています。アカウントをまだ作成していない場合は、AWS ホームページの [Create an AWS Account] を選択してください。
  • コンテンツデザイナー UI を使用して、質問と回答を QnABot に挿入する。
  • ウェブクライアント UI で音声またはチャットを使用して質問をする。
  • 最新の Amazon Echo デバイスを使用してハンズフリーで質問をする。
  • QnABot のコンテンツのトラブルシューティングと調整を行って、間違った回答が表示される可能性を最小限に抑える。
  • 画像やウェブリンクによって回答を強化する。

さらに、QnABot のしくみについても詳しく調べ、ニーズに合わせて強化するためのアイデアも示します。

(more…)

Build a Voice Kit with Amazon Lex and a Raspberry Pi

この記事では、広範に利用可能なコンポーネントを利用して、Amazon Lex をどのようにカスタムハードウェアに組み込むかを紹介します。シンプルな音声ベースの AI キットを構築して、Amazon Lex に接続する方法を示します。Raspberry Pi および合計 60 ドル以下の市販のコンポーネントをいくつか使用します。このブログの終わりまでに、Amazon Lex PostContent API に統合された、インターネット接続されたハードウェアデバイスが使用できるようになります。音声制御ロボットおよび音声制御メトロノームなどの、幾つかのボットのデモも行います。

コンポーネント概要

Amazon Lex ハードウェアキットを構築するには、以下のコンポーネントが必要です。

  • Raspberry PI 3 Model BAmazon で 35 ドルから。
  • Kinobo – USB 2.0 ミニマイク、Amazon で 5 ドルから。
  • Adafruit I2S 3W ステレオスピーカーボンネットおよびスピーカー、adafruit で 12 ドルから。
  • (オプション) Qunqi クリアーケースボックスエンクロージャー、Amazon で 20 ドルから。

物理的な作成

Raspberry Pi

図 1. Raspberry PI Model B

このプロジェクトでは、Raspberry PI 3 Model B ストックを使用します。図 1 は、Raspberry Pi をクリアーケースボックスキットに設置したところです。クリアーケースボックスは Pi、デジタルオーディオコントローラー (DAC)、およびスピーカーを置くのにちょうどぴったりですが、必須ではありません。

(more…)

近日公開:AWS MarketplaceにおけるSLES for SAP

AWSでSAP Partner Solutions Architectを務めるSabari Radhkrishnanによる記事です。

 

Amazon Web Services(AWS)とSUSEは、SUSE Linux Enterprise Server(SLES)を共同のSAP顧客に提供できるよう、長年に渡って協力してきました。AWSが2012年にSAP HANA Oneを含むSAPワークロードのプラットフォームとして初めて認定されてから、お客様はAWS上でSAPアプリケーションを実行するためにSLESオペレーティングシステムを使用してきました。AWSが2014年にSAP HANAのインスタンスとして認定されてからは、お客様はAWS上のSAP HANAの展開にもSLESを使い始めました。2015年に、SUSEの独自のサブスクリプションプログラムを通じて、SLES for SAPがAWS上で利用可能になりました。2016年には、SLES for SAPをオンデマンドイメージとしてAWS Marketplaceから利用できるようになり、既存および新規のお客様がミッションクリティカルなSAPワークロードをより簡単に始められるようになっています。

共同のSAP顧客に最高の体験を提供するための継続的な取り組みの一環として、2017年第4四半期にAWSのオファリングとしてSLES for SAPがAWS Marketplaceから利用できるようになることを本日発表します。これは、約7年前にSLESを提供開始して以来、AWSとSUSEによる2つ目の共同リストになります。SAP HANAのようなインメモリ・ワークロード用に特別に設計されたX1およびX1eインスタンスの提供により、開発、テストおよび本番環境のSAPワークロードをAWS上で稼働するお客様が増えています。

新しいSLES for SAPは、AWSとSUSEの共同サポートが受けられ、競争力のある価格で提供されるため、AWS上でSAPワークロードをより簡単に実行できるようになります。AWSとSUSEは、AWS上のSAPワークロード向けのOSを最適化し、強化するために協力し続けます。

SLES for SAPには、HAE(High Availability Extension)が含まれているため、SAP HANAインスタンスをアベイラビリティゾーンをまたがってシームレスにフェールオーバーできます。このソフトウェアには、ページキャッシュ管理やSAPワークロード用に最適化されたカーネル設定といった様々な拡張機能も含まれています。さらに、SLES for SAPイメージは長期サービスパックサポートに対応しているため、お客様は最新から2つ前のサービスパックを最大18ヶ月間使用することができます。SLES for SAPを使用する利点の詳細は​​、SUSE Webサイトを参照してください。

お客様は、AWS Quick Start for SAP HANAを使用して、SAP HANAワークロード用のSLES for SAPを簡単に始めることができます。このクイックスタートは、AWS、SAP、そしてSUSEのベストプラクティスに従って、SAP HANAの導入に必要なインフラストラクチャの構築と設定を1時間以内で行うのに役立ちます。

お客様は、引き続きSUSEのBYOS(bring-your-own-subscription)プログラムを活用することで、既存のサブスクリプションを使用してAWS上でSAPワークロードを実行することができます。詳細は、 http://aws.amazon.com/suseを参照してください。SAP on AWSの詳細については、http://aws.amazon.com/sapをご覧ください。

この発表の詳細については、SUSE blogを参照してください。

もし、SUSECONに参加されるなら、以下のSUSEとAWSのセッションも確認していただけると幸いです:

翻訳はPartner SA 河原が担当しました。原文はこちらです。