Category: Compute

Amazon Linux AMI は 2010 年 9 月の提供開始以来、数多くのお客様の Amazon Elastic Compute Cloud (EC2) による Linux ベースのアプリケーションのビルドを支援してきました。2017 年には、お客様にさらなるセキュリティ、安定性、生産性をもたらすために Amazon Linux 2 を導入しました。新機能を多数追加搭載しながら、当社では Amazon Linux 2 を長期的にサポートしてまいりました。お客様の新しいアプリケーションに役立てていただきたいと願っています。 よくある質問 でも申し上げたとおり、Amazon Linux AMI (2018.03) の最新バージョンは 2020 年 6 月 30 日にセキュリティアップデートの提供が終了します。お客様のご要望もあって、終了期日を延長し、メンテナンスサポート期間を設けます。 終了期日の延長 Amazon Linux AMI は 2020 年 12 月 31 日まで延長され、引き続きセキュリティアップデートおよびパッケージの更新版を必要に応じて提供することになりました。 メンテナンスサポート 2020 年 12 月 31 日を過ぎると […]

本投稿は、Principal Solutions Architectである George Maoの寄稿によるものです。   更新 – (2020年6月30日 PDT): MySQLおよびPostgreSQL対応のAmazon RDS Proxyが一般にご利用可能になりました。 更新 – (2020年4月8日 PDT): PostgreSQL 互換の Amazon RDS Proxy (プレビュー)を発表しました。プレビューではバージョン10.11と11.5がサポートされています。 AWSサーバーレスプラットフォームは、デマンドに応じて自動的に拡張するアプリケーションを構築することができます。大量アクセスがある間、 Amazon API Gateway と AWS Lambda は負荷に応じて自動的にスケールします。 多くの場合、開発者は、Lambda関数からリレーショナルデータベースに保存されたデータにアクセスする必要が出てきます。しかし、Lambdaからデータベースへの多すぎるコネクションにより過負荷にならないようにすることは難しい場合があります。リレーショナルデータベースの最大同時接続数は、データベースのサイズによって異なります。 これは、各コネクションがデータベースサーバー上のメモリとCPUリソースを消費するためです。Lambda関数は数万の同時接続数までスケールできるため、それに対応するには、データベースはクエリを実行するだけでなく、コネクションを維持するためにより多くのリソースが必要になります。 スケーリングの詳細については、アーキテクチャブログの投稿「サーバーレスアプリを大規模に設計する方法」も参照してください。 RDSを使用したサーバーレスアーキテクチャ Lambdaは数万の同時リクエストに応じて簡単にスケールできるため、そのような状況において、この設計ではバックエンドのリレーショナルデータベースに高い負荷がかかります。通常は、リレーショナルデータベースは、Lambdaのスケーラビリティに応じた同時接続を受け入れるように設計されていません。 Amazon RDSのデータベースプロキシ 本日(2019年12月3日 PST)、Amazon RDS Proxyのプレビューを発表できることを嬉しく思います。 RDS Proxyは、アプリケーションとRDSデータベースの間の仲介役として機能します。RDS Proxyは、必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑えます。 データベースへのSQL呼び出しを行うアプリケーションには、RDS Proxyを使用できます。ただし、サーバーレスのコンテキストでは、これによりLambda利用の体験がどのように改善されるかに焦点を当てています。RDS Proxyは、Lambda関数からデータベースに直接流れるすべてのデータベーストラフィックを処理します。 Lambda関数は、データベースインスタンスではなくRDS Proxyと対話します。RDS Proxyは、Lambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。 RDS Proxyは自動的にスケーリングされるため、データベースインスタンスでコネクション管理に必要なメモリとCPUリソースが少なくなります。また、暖機されたコネクションプールを使用することでパフォーマンス向上にもつながります。RDS Proxyを使用すると、アイドル接続のクリーンアップとコネクションプールの管理を処理するコードが不要になります。Lambda関数コードは、より簡潔でシンプルとなり、保守性が向上します。 Amazon […]

皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー（日本語版）がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS（英語版）の日本語版になります。   ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」（日本語版）というタイトルの51ページのドキュメントで、 はじめに モダンアプリケーション開発 モダンアプリケーションの設計パターン AWSでのCI/CD まとめ の各章から構成されています。各章の簡単なご紹介は下記の通りです。

これは Floating Point Group によるゲスト投稿です。彼らの言葉を借りると、「Floating Point Group は、機関投資家レベルの取引サービスを暗号通貨の世界にもたらすことをその使命としています」。 デジタル資産の取引向けに設計された金融インフラの必要性と需要はどれだけあるのかは、はっきりしないかもしれません。コインとトークンは、通貨、商品、株式、債券などの従来の資産に効果的にネイティブに相対するデジタル商品であると、広く受け止められています。この説明はよく、専門家が仮想空間内のさまざまなプロジェクトの価値提案を伝えようとするときに、力強く簡潔に伝えるために繰り返し用いられています (「ビットコインは、アルゴリズムで制御された改ざん防止の財務ポリシーが備わった、単なる通貨です」、または、「イーサリアムは、ガソリンのような金融商品です。それを使って、グローバルコンピューターの計算作業に支払うことができます」)。驚くことではありませんが、FPG である質問をよく耳にします。「暗号通貨が専用の金融サービスであることを保証するのに特別な点は何かありますか? なぜすでに解決された問題の解決策が必要なのですか」 実際、これらの資産とそれを取り巻く広範な公共の利益には、まったく前例がありません。ネットワークトランザクションのイミュータブルな記録として機能する分散型台帳テクノロジー。合理的なアクターを経済的に動機付けてネットワークのセキュリティを維持するためのプルーフオブワークアルゴリズムの巧妙な使用 (プルーフオブワークの概念は少なくとも 1993 年まで遡りますが、このテクノロジーが広く採用される可能性が示されたのは、ビットコインが登場してからです)。人的ミスや強要などの場合に固有の法的課題を引き起こす不可逆的な取引の性質。自己管理の不安定性 (サードパーティの保管ソリューションには、信頼を高める実績はありません)。これらの資産を分類することと、最終的に IRS、SEC、CFTC のようなエンティティによって調整する必要がある通貨交換を仲裁することの両方の困難を伴う規制上の不確実性。これらはすべて、非常に新しく、非常に特異なものです。24 時間取引が行える市場の規模は定期的に 1,000 億 USD を超えており、この記事では特にこれらの資産の取引に関連する問題に焦点を当てます。 確かに、仮想通貨取引は、ウェブフォーラムでビットコインを交換し始め、国際取引所間で 10% の価格スプレッドが確認されて以来、間違いなく成熟してきました。しかし、まだ長い道のりがあります。 機関投資家のために取り組むことを目指す上で抱える主な問題点の 1 つに、流動性 (またはより正確には、流動性の欠如) の問題があります。簡単に言えば、暗号通貨の売買は多くの異なる取引の場 (取引所) で行われ、流動性 (特定の価格で特定の量の資産を売買するオファー) は、新しい取引所が出現するにつれて断片化し続けています。100 ビットコインを購入しようとしているとしましょう。あなたは売りたい人から買う必要があります。最良の (最も安い) オファーを取得するにつれ、残りのオファーはどんどん高価になります。注文を完了するまでに (この例では、100 ビットコインをすべて購入するまでに)、たとえば注文の最初のビットコインに支払った価格よりも平均的にはるかに高い価格を支払うことになったかもしれません。この現象はスリッページと呼ばれています。スリッページを最小限に抑える 1 つの簡単な方法は、オファーの検索範囲を広げることです。そのため、1 つの取引所のオファーを見るのではなく、数百の取引所のオファーを見るのです。このプロセスは、従来スマートオーダールーティング (SOR) と呼ばれ、当社が提供するコアサービスの 1 つです。当社の SOR サービスにより、トレーダーは数十の取引所の流動性を積極的に監視することで、システムが複数の取引所で利用できる最高のオファーとマッチする注文を簡単に送信できます。 最良の価格を求めて大量注文を出すことは、かなり直感的で広く適用できる概念です。株式の約 75% が SOR を介して売買されています。けれども、暗号化市場向けのこのようなサービスの価値は特に顕著です。既存の取引所が行き詰まる中、新しい取引所が人気を博すという永続的なサイクルのため、取引所全体で流動性が絶え間なく断片化されています。けれどもトレーダーは、取引所に依存しない考え方を持つ傾向があります。ある特定量の資産にとって最良の価格を見つけることにのみ関心があるのです。 […]

10 年以上前にリリースして以来、Amazon EC2 インスタンスメタデータサービス ( IMDS ) は、安全でスケーラブルなアプリケーションの構築を支援してきました。IMDS は、一時的な認証情報へのアクセスを提供することで、クラウドユーザーにとって大きなセキュリティ上の課題を解決し、手動またはプログラムによってインスタンスに機密認証情報をハードコードしたり、配布したりする必要をなくしました。EC2 インスタンスにアタッチされた IMDS は、特別な「リンクローカル」の IP アドレス 169.254.169.254 で接続され、インスタンスで実行中のソフトウェアだけがアクセスできます。アプリケーションは IMDS にアクセスして、インスタンス、ネットワーク、およびストレージに関するメタデータを利用できます。また、IMDS は、インスタンスにアタッチされている IAM ロール による AWS 認証情報を使用できるようにします。 クラウドでアプリケーションを実行する場合、アプリケーションのセキュリティはインスタンスのセキュリティと同様に重要です。インスタンスで実行されているアプリケーションに脆弱性や設定ミスがあると、重大な問題が生じる可能性があります。アプリケーションセキュリティは多層防御において重要な役割を果たしますが、AWS はインスタンス内であっても、このような状況による被害の可能性を最小限に抑えるために、防御レイヤーを追加する場所をいつも検討しています。 本日、EC2 インスタンスメタデータサービスの v2（ IMDSv2 ）が利用可能になりました。既存のインスタンスメタデータサービス（ IMDSv1 ）は完全にセキュアであり、こちらも引き続きサポートします。しかし、IMDSv2 は、IMDS へのアクセスを試みる可能性がある４種類の脆弱性に対して新しい保護を追加します。この新しい保護は、IAM ロールの制限や、ローカルファイアウォールのルールを使用した IMDS へのアクセス制御など、既存の緩和策とシームレスに連携しますが、これらの緩和策よりも効果的に機能します。また、IMDSv2 をサポートする新しいバージョンの AWS SDK および CLI も利用可能です。 IMDSv2 の新機能 IMDSv2 では、すべてのリクエストがセッション認証によって保護されるようになりました。このセッションは、EC2 インスタンスで実行中のソフトウェアがリクエストするもので、ローカルに保存されている EC2 インスタンスのメタデータと認証情報にアクセスするためのものです。ソフトウェアは、IMDSv2 への単純な HTTP PUT リクエストを使用してセッションを開始します。IMDSv2 […]

本日、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 […]

本日の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を使うのにまたとないチャンスが訪れていると言えるでしょう。 […]

昨年の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シミュレーション: […]

社会人になったばかりの頃、開発チーム向けのOSイメージビルドの仕事がアサインされたのを今でも思い出します。時間はかかるし、エラーはよく出るし、再作成とスナップショット再取得をなんども実行する必要がありました。さらに、ご想像のとおり、そのあとには大量の手動テストが控えていたのです。 OSを最新に保つことの重要性は現在も変わりません。場合によっては自動化スクリプトを開発してくれるチームがあるかもしれませんが、いずれにせよVMのスナップショットを手動で取得するという作業は、多くのリソースを消費し、都度エラー対処が要求される、時間のかかる作業であることに変わりはありません。今日ここで、EC2 Image Builderを発表できることを大変うれしく思います。これは、自動化されたビルドパイプラインによる、簡単、かつ高速にセキュアなWindows ServerおよびLinux OSイメージをビルドし保守していくためのツールです。EC2 Image Builderで作成されたイメージは Amazon Elastic Compute Cloud (EC2)で用いることができ、また満たすべき情報セキュリティ基準を遵守できるよう、セキュリティを強化することができます。今後AWSは規制を受ける業界向けに、はじめの一手として使える“Security Technical Implementation Guide (STIG – セキュリティ設定チェックリスト)”に準拠したセキュリティ強化ポリシーを提供していきます。 EC2 Image Builderパイプラインに含めることのできる設定項目は、OSイメージのレシピ、基盤の構成、イメージの配布先、それからテスト構成です。さらに、セキュリティパッチを含むソフトウェアアップデートに応じて、イメージビルドを自動実行する機能も含まれます。パイプラインにより新たなイメージが作成されたタイミングで、各AWSリージョンにイメージを配布する前に検証すべきテストの自動実行を設定することもできます。またEC2 Image BuilderをEC2 VM Import/Export機能と併用することで、オンプレミスに存在するVMDK, VHDX, OVFそれぞれのフォーマットからなるVMイメージと連携することができます。自動テスト機能ではAWS提供のテストとユーザー定義のテストを組み合わせることもできます。 それでは、EC2 Image Builderの開始方法を見ていきましょう。 OSイメージビルドパイプラインの作成 AWSマネジメントコンソールのサービス一覧からEC2 Image Builderを選択し、EC2 Image Builderマネジメントコンソールに進みます。ここで”Create Image Pipeline”ボタンをクリックします。今回はAmazon Linux 2イメージをカスタマイズしてビルドすることにします。はじめの一歩はソースになるOSイメージを選択し、イメージに適用するビルドコンポーネントを指定し、実行するテストを構成するレシピを定義するところからです。 OSソースイメージの選択では、EC2 Image Builderの提供するAWS管理のイメージを選択しました(“Select managed images”).  この手順では他にも、自分で作成したAMIや共有されたAMIを選択することもできます。AMI IDを直接指定することができます。 “Browse images”ボタンを押すとAWS管理のイメージを選択する画面が開きます。イメージを選択するには、OS名のボックス右上のラジオボタンをクリックします。 続いてイメージに適用するビルドコンポーネントを指定します。これはインストールすべき追加ソフトウェアを指定する手順です。ウィザードの”Create build component”をクリックすると、ユーザー定義の新しいビルドコンポーネント作成のためのオプションを指定することができます。新規にビルドコンポーネントを作成するには、ビルドコンポーネントの名前(と説明書き), OS種別、コンポーネント暗号化のためのAWS Key […]

ほぼ10年前、エイプリルフールの日にQuantum Compute Cloudについて書きました。未来が到来し、量子アルゴリズムを作成して実際の量子コンピューターで実行する機会が得られました。本日発表する内容は次のとおりです。 Amazon Braket –科学者、研究者、開発者が1か所で複数の量子ハードウェアプロバイダーのコンピューターで実験を開始できるようにする完全に管理されたサービスです。サービスの名称は、一般に量子力学的な状態を示すために使用されるブラケット表記にインスパイアされました。 AWS量子コンピューティングセンター – カリフォルニア工科大学（Caltech）に隣接する研究センター。世界をリードする量子コンピューティングの研究者とエンジニアを集めて、量子コンピューティングハードウェアとソフトウェアの開発を加速します。 Amazon Quantum Solutions Lab – AWSの顧客をAmazonの量子コンピューティングの専門家と非常に厳選されたコンサルティングパートナーのセットと結びつける新しいプログラムです。 量子コンピューティングとは 通常の（古典的な）コンピューターは、ビットのコレクションを使用して状態を表します。各ビットは明確に0または1であり、nビットがある場合、可能な状態の数は2 ^ nです。1ビットは2つの状態のいずれかになり、2ビットは4つの状態のいずれかになります。1 MiBのメモリを搭載したコンピューターには、CPUレジスタと外部ストレージを除く2つの状態（8 * 1048576）があります。これは大きな数ですが、有限であり、計算できます。 量子コンピューターは量子ビット(qubit)と呼ばれるより洗練されたデータ表現で状態を記述します。各量子ビットは状態1または0に存在できますが、1と0の重ね合わせにも存在できます。つまり、量子ビットは両方の状態を同時に占有します。このような状態は、1組の複素数を含む2次元ベクトルによって指定でき、無限の数の状態になります。各複素数は確率振幅であり、基本的に量子ビットがそれぞれ0または1である確率です。 古典的なコンピューターは、特定の時間にそれらの2 ^ n状態のうちの1つだけになることがありますが、量子コンピューターはそれらすべてを並行して占有できます。 長期間ITに携わっていたなら、ムーアの法則によって、私がこれを書いているように2テラバイトをサムドライブに保存するメモリチップを製造できるようになったことを知っています。これを可能にする物理的および化学的プロセスは驚くべきものであり、研究する価値があります。残念ながら、これらのプロセスは量子ビットを含むデバイスの製造には直接適用されません。私がこれを書いているとき、最大の量子コンピューターには約50量子ビットが含まれています。これらのコンピューターはいくつかの異なる技術で構築されていますが、共通する2つの属性があるようです。それらは希少であり、慎重に制御された物理環境で実行する必要があります。 動作方法 量子コンピューターは、状態ベクトルの振幅を操作することにより動作します。量子コンピューターをプログラムするには、必要な量子ビット数を把握し、それらを量子回路に配線して実行します。回路を構築するとき、正しい答えが最も可能性の高いものであり、残りのすべてが非常にありそうもないようにそれを設定します。古典コンピューターはブール論理を使用しないで使って構築され、OR、およびANDゲートに対し、量子コンピューターは、重ね合わせとの干渉を使用し、使用して構築されている量子論理ゲートを、新しいとエキゾチックな名前（X、Y、Z、CNOT、アダマール、トフォリなど）で構成します。 中期暗号化とデータ保護を検討する際には、これを念頭に置く必要があります。また、ポスト量子暗号について知る必要があります。現在、s2n（TLS / SSLプロトコルの実装）には、すでに量子耐性のある2つの異なるキー交換メカニズムが含まれています。新しい暗号化プロトコルが広く利用可能になり安全に使用できるようになるには約10年かかることを考えると、大規模な量子コンピューターが利用可能になる時期を先取りするのに早すぎるということはありません。 量子コンピューティングは今日主流ではありませんが、その時が来ています。これは、古典的に解決することが困難または不可能な特定の種類の問題を解決できる非常に強力なツールです。40年または50年以内に、量子コンピューターで実行されるサービスを使用して、多くのアプリケーションが部分的に機能するようになると思います。そのため、GPUまたは数学コプロセッサーのように考えるのが最善です。それらは単独では使用されませんが、ハイブリッド古典/量子ソリューションの重要な部分になります。 私たちの目標は、いくつかの適切なユースケースを探しているあなたに、いくつかのテストや実験を行う開始する量子コンピュータについて十分に知っているようにすることです。私たちは、現実にしっかりと根ざした強固な基盤を構築し、あなたと協力して、量子の力を活用した未来に移行したいと考えています。 Amazon Braket この新しいサービスは、量子ビットと量子回路を実際に体験できるように設計されています。シミュレーション環境で回路を構築およびテストしてから、実際の量子コンピューターで実行できます。Amazon Braketは完全に管理されたAWSサービスで、各レベルでセキュリティと暗号化が組み込まれています。 ノートブックスタイルのインターフェースを介してAmazon Braketにアクセスできます。 PythonコードはAmazon Braket SDKを利用します。1行のコードで量子回路を作成できます（これは、私の同僚によると、「量子ビット0と量子ビット1が最大にもつれた (エンタングルした) ベル状態」とのこと）。 bell = Circuit().h(0).cnot(0, 1) そして別のものでそれを実行します： print(device.run(bell, s3_folder).result().measurement_counts()) 古典計算機の力を借りたシミュレーション環境に加えて、Amazon Braketがアクセスを提供するD-Wave、IonQ、およびRigettiの量子コンピュータがあります。これらのデバイスにはいくつかの共通点があります：最先端の技術であり、構築と実行に費用がかかり、通常、電気のない状態に保つ必要がある非常に極端で特殊な環境（過冷却または真空に近い）で動作します。まとめると、ほとんどの組織が量子コンピューターを所有することは決してなく、クラウドベースのオンデマンドモデルの方が適していると考えています。プロダクション規模の量子コンピューターが最初はクラウドのみのテクノロジーである場合もあります。 実際の量子コンピューターは芸術作品であり、いくつかのクールな写真を共有できることを嬉しく思います。D-Wave 2000Qは次のとおりです。 The Rigetti 16Q Aspen-4： そして、IonQリニアイオントラップ： AWS量子コンピューティングセンター […]