Amazon Web Services ブログ

By Nathaniel Kangpan, SVP Technology & Data Services, Kepler Group 私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。ハードウェアからクラウドへ移行した場合のTotal Cost of Ownership(TCO)の節約は無視できません。 しかし、所有しているハードウェアからAWSのようなクラウドベースのインフラストラクチャに移行する際には、本当に何を期待するべきですか？ Amazon EC2などの仮想サーバー上にソリューションを複製するだけでいいですか、Amazon RDSのようなマネージドサービスを増やすべきででしょうか？ Kepler Groupでは、インフラストラクチャの95％以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。   Global Fortune 100の例 私たちは通常、Global Fortune 100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。その後、MySQLを実行しているEC2インスタンスに移行し、最終的にAmazon Aurora MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。 今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。 このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。クライアントのニーズを満たすことに加えて、次の点に細心の注意を払う必要がありました: データベースメンテナンスの負荷を低く抑える インフラストラクチャコストの制限 信頼性の高いバックアップおよびリカバリプロセスを確保する 前述のように、データベース用に3つの異なるインフラストラクチャソリューションを使い、各バージョンのメリットと課題についてかなりのことを学びました: v1.0：オンプレミスハードウェア上のLinuxでMySQLを実行する v2.0：Amazon EC2上のLinuxでMySQLを実行する v3.0：MySQLと互換性を持つAmazon Aurora 次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。   Version 1.0: オンプレミスハードウェア上のLinuxでMySQLを実行する 2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。 利点 この初期のアプローチの唯一のメリットは、エンジニアがハードウェア+ Linux + MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。 チャレンジ しかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。AWSへの移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。具体的には、クラウドと比較してハードウェアソリューションでは次のような課題に直面しました: かなり高いサーバーとデータベースのメンテナンスとアップグレードの運用負荷 時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセス […]

AWS Glue は、Hive 形式で整理されたデータセットの高度な取扱いをサポートします。AWS Glue クローラーは、自動的に Amazon S3 データのパーティションを識別します。AWS Glue ETL (Extract/Transform/Load) ライブラリは、DynamicFrame を取り扱う際、ネイティブでパーティションをサポートします。DynamicFrame はデータの分散コレクションを表します。スキーマを指定する必要はありません。DynamicFrame の作成時に述語をプッシュダウンしてパーティションをフィルタリングし、高コストの S3 への呼び出しを回避できます。また、Apache Spark DataFrame に変換することなく直接パーティショニングされたディレクトリに書き込む機能のサポートを追加しました。 パーティショニングは、データセットを様々なビッグデータシステムで効率的にクエリできるように、それらを整理するための重要な手法となっています。データは、ひとつまたは複数の列の重複しない値に基づいて、階層ディレクトリ構造にまとめられます。たとえば、Amazon S3 のアプリケーションログを、年別、月別、日別の内訳で日付ごとにパーティショニングするとします。すると、1 日分に相当するデータがs3://my_bucket/logs/year=2018/month=01/day=23/のようなプレフィックスの下に配置されます。 Amazon Athena、Amazon Redshift Spectrum、AWS Glue などのシステムでは、これらのパーティションを使用して値ごとにデータをフィルタリングできるため、Amazon S3 への不要な呼び出しを行う必要がありません。このため、読み取る必要のあるパーティションが少ないアプリケーションのパフォーマンスが大幅に改善します。 本投稿では、AWS Glue を使用してパーティショニングされたデータセットを効率的に処理する方法を紹介します。まず、クローラーを設定して、パーティショニングされたデータセットを自動的にスキャンし、AWS Glue データカタログにテーブルとパーティションを作成する方法を説明します。次に、パーティショニングされたデータを取り扱うための AWS Glue ETL ライブラリの機能をいくつか紹介します。SQL 式やユーザー定義の関数を使用してパーティションをフィルタリングし、Amazon S3 からの不要なデータのリスト作成や読み取りを回避することができます。また、ETL ライブラリでは、Spark SQL DataFrame に依存することなく、AWS Glue DynamicFrame をパーティションに直接記述する機能のサポートを追加しました。 それでは、始めましょう。 パーティショニングされたデータのクローリング この例では、以前の […]

Elasticsearch および Amazon Elasticsearch Service (Amazon ES) に関するこの導入シリーズへようこそ。今回および今後のブログ記事では、AWS で Elasticsearch の使用を開始するために必要な基本情報を紹介します。 概要 IAM ポリシーまたは Amazon Resource Name (ARN) のポリシーを使用して、ユーザーまたはロールを指定し、Amazon Elasticsearch Service ドメインへのアクセスをコントロールしている場合は、ドメインへのすべてのリクエストに対し AWS Signature Version 4 (AWS SigV4) を使用して署名する必要があります。ドメイン保護に関するさらに詳しい分析については、こちらのブログ記事もご参照ください。ポリシーの考察およびその問題解決に関する詳細は、こちらのブログ記事をご参照ください。 リクエストへの署名に関する AWS ドキュメントを読んでいただければ、非常に複雑に見えるプロセスが理解できるようになります。難しく見えますが、3 つのオープンソースライブラリを使用して、コードをいくつか書き、署名して Amazon ES にリクエストを送信するのはとても簡単です。ここでは Boto3、Python Requests ライブラリ、Requests AWS4Auth ライブラリを使用します。 コードスニペット 次のコードスニペットには、HTTP メソッド、呼び出す URL、呼び出すサービス、AWS リージョン、オプションのリクエストボディがあります。このコードでは、Boto3 の Session クラスを使用して認証情報を取得しています。Boto3 が認証情報を決定する方法の詳細については、Boto3 のドキュメントを参照してください。AWS4Auth クラスが認証情報を使用してリクエストに署名します。最後に、Requests ライブラリが Amazon ES […]

AWS で Microsoft SQL Server をデプロイするときは、アプリケーションのパフォーマンス、可用性、信頼性、およびコストをどのように最適化するかに関する数多くの選択肢があります。Amazon では、使用方法を最適化し、コストを削減するために、複数の SQL Server バージョン、幅広いコンピューティングオプション、および多数のライセンスオプションをご用意しています。従量制料金モデルを選択して AWS のライセンスが包含されたオプションを使用する、または Amazon EC2 で独自のライセンスを使用する (BYOL) ことができます。 EC2 インスタンスで利用できる SQL Server 2017 には、Amazon EC2 で実行される Microsoft Windows または Linux オペレーティングシステムのどちらかに SQL Server ベースのアプリケーションをデプロイする柔軟性があります。AWS は本日、ライセンスが包含された Amazon Machine Image (AMI) を提供することによる、Amazon Linux 2 および Ubuntu での Microsoft SQL Server のサポートを発表しました。このリリースでは、ライセンスが包含された AMI を EC2 コンソールから直接使用して、Amazon Linux 2 LTS […]

こんにちは。コミュニティプログラム担当の沼口です。JAWS-UG(Japan AWS User Group)は全国50以上の支部から成り立っており、それぞれの地域で独自に勉強会を企画、開催しています。各支部で勉強会が完結している場合が多いのですが、東京で開催されたJAWS DAYS 2018のre:Cap（参加できなかった人向けに、実際に参加した人がセッション内容を紹介する勉強会）などを地方単独でやるのは、登壇者への負担が大きいという課題がありました。 先日(2018/4/13)、石川県の金沢支部、静岡県の磐田支部、愛知県の名古屋支部の3つの勉強会会場をAWSが提供する統合コミュニケーションサービスの「Amazon Chime」を使い、それぞれの支部からJAWS DAYS 2018 re:Capの登壇者を募り、3元中継で合同勉強会を開催しました。各支部の勉強会会場からChimeを使って、プレゼンテーション画面の共有と音声と映像を配信することで、3名3地域の登壇者によるre:Capプレゼンテーションを実施し、JAWS DAYSで印象に残ったセッションの紹介、参加した感想などを参加メンバーと共有することができました。                     [金沢会場の登壇者によるプレゼンテーション]                   [各支部の模様はWebカメラを通してChimeで確認可能]                   [他支部のプレゼンテーションをプロジェクターで視聴]   Amazon Chimeを使った感想として、映像、音声ともにオンライン中継で使えるレベルである、という高評価をいただきました。一部、会場のスピーカーによっては聞きづらかったケースもありましたが、テレビ会議用のスピーカーフォンを準備したり、PCから会場に設置されている音響機器にケーブル接続したりすることで問題がない、というお墨付きをいただきました。一方、共有画面のウィンドウを間違えてしまった、プレゼンテーション中のポインターの利用方法など、今後ノウハウを蓄積・共有すべき点も明確になってきました。   各支部各地域の熱心なユーザーによる勉強会によって支えられているJAWS-UGですが、地方支部単独開催になるとコアリーダーの負担が大きくなりがちです。AWSは弊社社員による登壇参加などでの勉強会支援もしていますが、このようにAmazon Chimeなどを提供することで、コアリーダーの負担を減らしながら、勉強会を盛り上げていけるよう、さまざまな支援をJAWS-UGに対して提案・実施しています。 オフラインによる勉強会の良さを維持しながらも、オンラインサービスを効果的に使うことで、JAWS-UGの方々の負担を軽減しながらも、楽しく、ためになる勉強会になることを期待しています。来月の5月に開催予定のJAWS-UG勉強会Alexa.Westも同じくAmazon Chimeを使って大阪、神戸、京都、岡山、和歌山をつなげて、5元中継の合同勉強会になる予定です。 JAWS-UG勉強会情報はJAWS-UGのホームページに掲載されているスケジュールか、AWSのホームページの「イベント＆オンラインセミナー」の「ユーザーグループ」のセクションで確認できます。ぜひチェックして興味のある勉強会に参加してはいかがでしょうか。   アマゾン ウェブ […]

こんにちは、マーケティングの鬼形です。 先日 (2018/4/11) 開催致しました AWS Black Belt Online Seminar「Amazon EC2」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

今回のブログでは、Amazon Elastic File System (EFS) を Amazon SageMaker ノートブックインスタンスにマウントする方法について説明します。この方法を使えば、大規模なデータセットを保存してアクセスすること、そして SageMaker ノートブックインスタンスからの機械学習スクリプトを共有することが容易になります。 Amazon SageMaker ノートブックには、Jupyter Notebook サーバーを実行している自分自身のインスタンスに高速にアクセスするための機能が用意されています。そこから、Amazon SageMaker の分散マネージドトレーニング環境にアクセスし、リアルタイムで、実用グレードのホストエンドポイントをセットアップすることができます。Amazon SageMaker の高速でスケーラブルなアルゴリズムや、構築済みディープラーニングフレームワークコンテナを使用できます。Amazon EFS はシンプルでスケーラブルなファイルストレージを提供します。これは同時に複数の AWS リソース間で共有することができます。これら 2 つを組み合わせれば、まさに自分のノートブック環境から、大規模な機械学習データセットや共有コードに簡単にアクセスできます。 現在のところ、 Amazon SageMaker のノートブックインスタンスは、5 GB の Amazon Elastic Block Store (EBS) ストレージから開始し、約 20 GB の非永続的ストレージに拡大するようになっています。さらに大きなファイルは Amazon S3 からアクセスできますが、ファイルシステムと同じほどの柔軟性は提供されていません。柔軟性と大規模なデータセットを必要とするユースケースでは、EFS をノートブックインスタンスにマウントすることにより、その要件を満たすことができます。一部の顧客はまた、すでに EFS をマウントして、ファイルを保存し、既存の EC2 インスタンスにわたって共有しています。これは EFS と Amazon SageMaker が協力できる、別の分野です。 既存の EFS […]

世界では毎日、数百万のユーザーがメール、ソーシャルネットワーク、およびチャットプラットフォームやメッセージボードなど、他のオンラインコミュニティを通じて互いに通信しています。しばしばユーザーは特定のコミュニティに興味を抱いてチャットの会話に参加したいと思いますが、オンラインコミュニティの第一言語がユーザーが理解できる言語とは異なる場合があります。 このようなコミュニティの 1 つがゲーマー向けの世界最大のソーシャルビデオサービスである Twitch です。毎日、共有している関心事について見たり、話したり、チャットしたりするために、数百万のコミュニティメンバーが集まります。チャットはどのストリームにも内蔵されているので、ストリームを受動的に見ている代わりに、ショーに参加することができます。あなたは Twitch にはあなたの言語を必ずしも話す必要のない多くのストリーマーがいることに気付きますが、それでもあなたはストリームを楽しんだり、チャットに参加したりしたいと思うかもしれません。 このようなコミュニケーションを実現するため、AWS は、高速、高品質、適正価格の言語翻訳機能を備えたニューラルマシン翻訳サービスである Amazon Translate を用意しています。Amazon Translate は、ユーザー間のクロスリンガルコミュニケーションを可能にするオンデマンド翻訳機能を提供します。チャット、メール、ヘルプデスク、チケット発行アプリケーションにリアルタイム翻訳機能を追加すれば、英語を話す担当者や従業員は複数の言語で顧客とコミュニケーションをとることができるようになります。 このブログポストは、Twitch チャネルで Amazon Translate を使ってクロスリンガルチャットを実現する方法をカバーします。あなたはまた、受信したリアルタイムメッセージを有声音で発音するテキスト読み上げサービス、Amazon Polly の使用法も学習します。この追加機能によって、アクセス機能が強化され、ユーザーは、他のタスクに集中しながらメッセージを聞くことができます。 ソリューションの概要 このポストでは、CSS と JavaScript を備えた HTML ページを作成します。JavaScript ライブラリを使用して、Twitch チャネルに接続し、メッセージの受信を開始します。リアルタイムメッセージを受信すると、AWS SDK を使用して Amazon Translate を呼び出し、翻訳されたこれらのメッセージを UI に表示します。音声オプションを有効にした場合、AWS SDK を使用して Amazon Polly を呼び出し、音声合成されたこれらのメッセージをユーザー先で再生します。 Twitch アカウントを作成して構成する twitch.tv に移動して、Twitch アカウントにサインアップします。 Twitch アカウントのサインアップに成功したら、https://twitchapps.com/tmi に移動して、Twitch OAuth トークンを作成します。 [Connect with […]

本日、Amazon SageMaker は、内蔵の線形学習者アルゴリズムに対して、いくつかの機能追加を実施しました。Amazon SageMaker アルゴリズムは、労力を必要とせずに巨大なデータセットにスケールし、比類のない速度を達成できる、最新のハードウェア最適化の利点を活用できるように設計されています。Amazon SageMaker の線形学習者アルゴリズムは、線形回帰および二項分類アルゴリズムの両方を包含しています。 これらのアルゴリズムは金融、不正/リスク管理、保健、ヘルスケアにおいて広く使われています。学習者アルゴリズムの新しい機能は、トレーニングの速度を向上させ、異なるユースケースに合わせてモデルをカスタマイズしやすくするものです。例としては、不均衡クラスによる分類が含まれます。これは、ある結果が別のものよりずっとまれにしか生じないような分類です。また、回帰に特化した損失関数もあります。特定のモデルエラーに対して、他のものよりも大きなペナルティを科すことが重要な場合に対応します。 このブログでは、次の 3 つの点を扱います。 最適なモデルに対しては早期に終了して保存すること。 線形学習者モデルをカスタマイズする新しい方法。次のものが含まれます。 ヒンジ損失 (サポートベクターマシン) 分位点損失 Huber 損失 イプシロン不感応損失 クラス重み付けオプション それから、二項分類におけるパフォーマンスを向上させるためにクラス重み付けを用いる例を実際に試してみます。 早期終了 線形学習者は、確率的勾配降下法 (SGD) または Adam のような SGD の変種を用いて、モデルをトレーニングします。トレーニングでは複数回にわたってデータを処理することが求められます。これはエポックと呼ばれています。データはバッチ、ときにはミニバッチと呼ばれる塊として、メモリに読み込まれます。エポックは何回実行するべきでしょうか。理想的には、収束するまでトレーニングを行いたいところです。つまり、これ以上繰り返しても利点が増えなくなるところまでです。モデルが収束してからもエポックを実行するのは時間とメモリの無駄ですが、適切なエポック数を推測するのは、実際にトレーニングジョブを実行するまでは困難です。トレーニングのエポック数が少なすぎると、モデルの精度は本来可能な精度よりも落ちてしまいます。しかし、エポック数が多すぎると、リソースが無駄になりますし、過剰適合によってモデルの精度が悪化する可能性もあります。当て推量を避け、モデルトレーニングを最適化するために、線形学習者には 2 つの新しい機能が追加されました。自動的な早期終了と、最適なモデルの保存です。 早期終了は 2 つの基本的様式で動作します。検証セット付きと検証セットなしです。多くの場合、データはトレーニング、検証、および試験データセットに分割されます。トレーニングは損失の最適化のため、検証はハイパーパラメーターのチューニングのため、試験はモデルがまだ得ていない将来のデータに対しどの程度のパフォーマンスを出せるかを、公平に見積もるために行われます。検証データセット付きの線形学習者アルゴリズムを提供した場合、検証損失について向上が見られなくなると、モデルのトレーニングは早期に終了します。検証セットが利用できない場合、トレーニング損失について向上が見られなくなると、モデルのトレーニングは早期に終了します。 検証データセット付きの早期終了 検証データセットを利用することの大きな利点としては、トレーニングデータに対する過剰適合が起きたかどうか、そしていつ起きたかについて判断できることが挙げられます。過剰適合は、トレーニングデータへの適合性が緊密すぎる予測をモデルが与えるようになって、汎化されたパフォーマンス (まだ得ていない将来のデータに対するパフォーマンス) が低下することを指しています。下のグラフの右側は、検証データセット付きのトレーニングの典型的な進行状況を示しています。エポック 5 までは、モデルはトレーニングセットからの学習を続けており、検証セットでの成績が次第に良くなっています。しかしエポック 7～10 では、モデルがトレーニングセットへの過剰適合を起こし始めていて、検証セットでの成績が悪くなっていきます。モデルがトレーニングデータでの向上 (過剰適合) を続けていたとしても、モデルが過剰適合を始めたら、トレーニングを終了しなければなりません。そして、過剰適合が始まる直前の、最善のモデルを復元する必要もあります。これらの 2 つの機能は、線形学習者ではデフォルトでオンになっています。 早期終了のためのデフォルトのパラメーター値を下のコードに示します。早期終了の動作をさらに調整するため、値の変更を試してみてください。早期終了を完全にオフにするには、early_stopping_patience の値を実行するエポック数より大きくしてください。 early_stopping_patience=3, early_stopping_tolerance=0.001, パラメーター early_stopping_patience は、改善が見られない場合にも、トレーニングを終了するまで何回のエポックを待つかを定義します。早期に終了することにした場合でも、このパラメーターをある程度の大きさにするのは有用です。学習曲線には凹凸ができることがあるからです。改善がまだ続く場合でも、パフォーマンスが 1 ないし […]

Amazon SageMaker は、データの探索と前処理用に Jupyter ノートブックを実行する、完璧なマネージドインスタンスを提供します。顧客は、構成済みのノートブックインスタンスをワンクリックで簡単に起動できることに大きな価値を見出しています。現在、私たちは、2 つの新しいオプションを提供することによってカスタマイズ性を向上させることに取り組んでいます。すなわち、ノートブックインスタンスのカスタマイズプロセスの自動化を支援するライフサイクル構成と、ノートブックインスタンスに制御されたセキュリティ環境を提供するために、ノートブックインスタンスをパブリックインターネットから切り離す機能です。 ノートブックインスタンスのライフサイクル構成 Amazon SageMaker は現在、追加ライブラリをノートブックインスタンスに手動でインストールする機能を備えています。しかし、ノートブックインスタンスを停止させると、これらの追加したカスタマイゼーションも、同時に削除されてしまいます。そのため、ノートブックインスタンスを再起動した場合、これらを再び手動で追加する必要があります。Amazon SageMaker の新しいライフサイクル構成機能を使用すると、これらのカスタマイゼーションをインスタンスのライフサイクルのさまざまなフェーズで適用するのを自動化することができるようになります。たとえば、一連のライブラリをインストールするスクリプトを作成し、ライフサイクル構成機能を使用して、ノートブックインスタンスが起動されるたびにスクリプトが自動的に実行されるように構成することができます。あるいは、ノートブックインスタンスが作成されたとき、スクリプトが一度だけ、自動的に実行されるように構成することもできます。 TurboTax や QuickBooks など、グローバルに製品およびプラットフォームを提供していることで知られる Intuit は、ライフサイクル構成を使用して、セキュリティスキャナーのデプロイや、ルーティングルールの再構成など、ノートブックインスタンスのセキュリティ環境をカスタマイズしています。また Intuit は、ノートブックインスタンスではインターネットへの直接アクセスを無効にし、ライフサイクル構成を使用して、VPC にデプロイされたプライベートパッケージインデックスを利用する、パッケージのインストールをブートストラップしています。 ノートブックインスタンスのインターネットへの直接アクセスを無効にするオプション 従来は、すべての Amazon SageMaker ノートブックインスタンスがデフォルトでインターネットへの直接アクセス権を持っており、それを無効にすることはできませんでした。これにより、パブリックインターネットから、人気のあるパッケージ、ノートブック、データセットをダウンロードしたり、他の Amazon SageMaker コンポーネントにアクセスしたりすることができました。しかし、ノートブックインスタンスを仮想プライベートクラウド (VPC) に接続すると、ノートブックインスタンスは、『ノートブックインスタンスのセキュリティ』で議論しているように、データアクセスのための余計なアベニューを装備することになります。その結果、いくつかの顧客から、インターネットアクセスを制御する機能についての要望がありました。特に、自社の VPC に接続するノートブックインスタンスについての要望です。現在、Amazon SageMaker ノートブックインスタンスのデフォルトのインターネットへの直接アクセスを無効にするオプションが用意されました。これを使用すると、VPC 構成を信頼して、ノートブックインスタンスにインターネットアクセスを許可するかしないかを制御させることができます。 これらの新しい機能について調べるために、Amazon SageMaker コンソールを開いて、ノートブックインスタンスを作成します。ページの下にある [Lifecycle configuration (ライフサイクル構成)] にナビゲートします。  始めて使用する場合、アカウントにはいかなるライフサイクル構成も含まれていないので、[Create a lifecycle configuration (ライフサイクル構成の作成)] を選択します。 最初のライフサイクル構成を作成するための作業ウィンドウがポップアップします。ライフサイクル構成を追加していけば、このウィンドウのドロップダウンリストから既存の構成を選択することができるようになります。 このポップアップウィンドウで、ライフサイクル構成に名前を付け、[Start notebook (ノートブックの起動)] または [Create […]