Amazon Comprehend を使用すると、機械学習の専門家でなくても、テキストからインサイトを引き出すことができます。Comprehend では、組み込みモデルを使用して入力文書の構文を分析し、エンティティ、イベント、キーフレーズ、個人を特定できる情報 (PII)、および特定のエンティティ (ブランドや製品など) に関連付けられた全体的なセンチメントまたは複数のセンチメントを見つけることができます。 11月9日、有害なコンテンツを検出する機能が追加されました。この新機能は、エンドユーザー向けにより安全な環境を構築するのに役立ちます。例えば、毒性検出を使用して、コメントなどの外部からの投稿を受け付けるアプリケーションの安全性を向上させることができます。生成系 AI を使用する際、毒性検出を使用して、入力プロンプトと大規模言語モデル (LLM) からの出力応答を確認できます。 毒性検出は、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK で使用できます。AWS CLI と AWS SDK を使った例で、これがどのように機能するかを見て、LLM の使用状況を確認しましょう。 AWS CLI で Amazon Comprehend Amazon Comprehend Toxicity Detection を使用する AWS CLI の新しい detect-toxic-content サブコマンドは、テキストに含まれる毒性を検出します。出力には、ラベルのリスト (入力内のテキストセグメントごとに 1 つ) が含まれます。各テキストセグメントに対して、複数のラベルと 1 つのスコア (0～1) を含むリストが表示されます。 例えば、次の AWS CLI コマンドは 1 つのテキストセグメントを分析し、1 つの Labels セクションと全体的な Toxicity スコア (0～1) が返されます。 aws comprehend detect-toxic-content --language-code en --text-segments Text="'Good morning, it\'s a beautiful day.'" { "ResultList": [ { "Labels": [ { "Name": "PROFANITY", "Score": 0.00039999998989515007 }, { "Name": "HATE_SPEECH", "Score": 0.01510000042617321 }, { "Name": "INSULT", "Score": 0.004699999932199717 }, { "Name": "GRAPHIC", "Score": 9.999999747378752e-05 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.0006000000284984708 }, { "Name": "SEXUAL", "Score": 0.03889999911189079 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.016899999231100082 } ], "Toxicity": 0.012299999594688416 } ] } 予想通り、すべてのスコアは 0 に近く、このテキストで毒性は検出されませんでした。 入力をファイルとして渡すには、AWS CLI --generate-cli-skeleton オプションを使用して、 detect-toxic-content コマンドで使用される JSON 構文のスケルトンを生成します。 aws comprehend detect-toxic-content --generate-cli-skeleton { "TextSegments": [ { "Text": "" } ], "LanguageCode": "en" } ここで、出力をファイルに書き込み、3 つのテキストセグメントを追加します (有毒なコンテンツで何が起こるかを示すために使用されるテキストは示しません)。今回は、さまざまなレベルの有害なコンテンツが見つかりました。各 Labels セクションは、対応する入力テキストセグメントに関連付けられています。 aws comprehend detect-toxic-content --cli-input-json file://input.json { "ResultList": [ { "Labels": [ { "Name": "PROFANITY", "Score": 0.03020000085234642 }, { "Name": "HATE_SPEECH", "Score": 0.12549999356269836 }, { "Name": "INSULT", "Score": 0.0738999992609024 }, { "Name": "GRAPHIC", "Score": 0.024399999529123306 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.09510000050067902 }, { "Name": "SEXUAL", "Score": 0.023900000378489494 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.15549999475479126 } ], "Toxicity": 0.06650000065565109 }, { "Labels": [ { "Name": "PROFANITY", "Score": 0.03400000184774399 }, { "Name": "HATE_SPEECH", "Score": 0.2676999866962433 }, { "Name": "INSULT", "Score": 0.1981000006198883 }, { "Name": "GRAPHIC", "Score": 0.03139999881386757 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.1777999997138977 }, { "Name": "SEXUAL", "Score": 0.013000000268220901 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.8395000100135803 } ], "Toxicity": 0.41280001401901245 }, { "Labels": [ { "Name": "PROFANITY", "Score": 0.9997000098228455 }, { "Name": "HATE_SPEECH", "Score": 0.39469999074935913 }, { "Name": "INSULT", "Score": 0.9265999794006348 }, { "Name": "GRAPHIC", "Score": 0.04650000110268593 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.4203999936580658 }, { "Name": "SEXUAL", "Score": 0.3353999853134155 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.12409999966621399 } ], "Toxicity": 0.8180999755859375 } ] } AWS SDK での Amazon Comprehend Toxicity Detection の使用 AWS CLI の場合と同様に、AWS SDK を使用してアプリケーション内の毒性をプログラムで検出できます。次の Python スクリプトは、 AWS SDK for Python (Boto3) を使用してテキストセグメント内の毒性を検出し、スコアが指定しきい値を超える場合はラベルを出力します。コードでは、2 番目と 3 番目のテキストセグメントの内容を編集して *** で置き換えています。 import boto3 comprehend = boto3.client('comprehend') THRESHOLD = 0.2 response = comprehend.detect_toxic_content( TextSegments=[ { "Text": "You can go through the door go, he's waiting for you on the right." }, { "Text": "***" }, { "Text": "***" } ], LanguageCode='en' ) result_list = response['ResultList'] for i, result in enumerate(result_list): labels = result['Labels'] detected = [ l for l in labels if l['Score'] > THRESHOLD ] if len(detected) > 0: print("Text segment {}".format(i + 1)) for d in detected: print("{} score {:.2f}".format(d['Name'], d['Score'])) Python スクリプトを実行します。出力には、2 番目と 3 番目のテキストセグメントで検出されたラベルとスコアが含まれます。最初のテキストセグメントでは毒性は検出されません。 Text segment 2 HATE_SPEECH score 0.27 VIOLENCE_OR_THREAT score 0.84 Text segment 3 PROFANITY score 1.00 HATE_SPEECH score 0.39 INSULT score 0.93 HARASSMENT_OR_ABUSE score 0.42 SEXUAL score 0.34 LLM での Amazon Comprehend Toxicity Detection の使用 このブログ記事 で説明されているように、 Amazon SageMaker JumpStart を使用して Mistral 7B をデプロイしました。 モデルの応答に毒性が含まれるのを避けるため、次の 3 つの関数を含む Python スクリプトを構築しました。 query_endpoint は、SageMaker JumpStart によってデプロイされたエンドポイントを使用して Mistral 7B モデルを呼び出します。 check_toxicity は Comprehend を使用してテキスト内の毒性を検出し、検出されたラベルのリストを返します。 avoid_toxicity は、検出されたラベルのリストを入力として受け取り、毒性を避けるために行うべきことを説明するメッセージを返します。 LLM へのクエリは、入力プロンプトで毒性が検出されかった場合にのみ実行されます。LLM からの応答は、出力に毒性が検出されなかった場合にのみ出力されます。毒性が検出された場合、スクリプトは入力プロンプトの修正方法に関する提案を提供します。 Python スクリプトのコードを以下に示します。 import json import boto3 comprehend = boto3.client('comprehend') sagemaker_runtime = boto3.client("runtime.sagemaker") ENDPOINT_NAME = "<REPLACE_WITH_YOUR_SAGEMAKER_JUMPSTART_ENDPOINT>" THRESHOLD = 0.2 def query_endpoint(prompt): payload = { "inputs": prompt, "parameters": { "max_new_tokens": 68, "no_repeat_ngram_size": 3, }, } response = sagemaker_runtime.invoke_endpoint( EndpointName=ENDPOINT_NAME, ContentType="application/json", Body=json.dumps(payload).encode("utf-8") ) model_predictions = json.loads(response["Body"].read()) generated_text = model_predictions[0]["generated_text"] return generated_text def check_toxicity(text): response = comprehend.detect_toxic_content( TextSegments=[ { "Text": text } ], LanguageCode='en' ) labels = response['ResultList'][0]['Labels'] detected = [ l['Name'] for l in labels if l['Score'] > THRESHOLD ] return detected def avoid_toxicity(detected): formatted = [ d.lower().replace("_", " ") for d in detected ] message = ( "次の有害なコンテンツを避けてください:" + ", ".join(formatted) + ".\n" ) return message prompt = "ウェブサイトは 10 のシンプルなステップで構築できます。" detected_labels = check_toxicity(prompt) if len(detected_labels) > 0: # 入力プロンプトで毒性が検出された場合 print("プロンプトを修正してください。") print(avoid_toxicity(detected_labels)) else: response = query_endpoint(prompt) detected_labels = check_toxicity(response) if len(detected_labels) > 0: # 出力で毒性が検出された場合 print("改善されたプロンプト:") prompt = avoid_toxicity(detected_labels) + prompt print(prompt) else: print(response) スクリプトのサンプルプロンプトでは毒性を含む応答は得られませんが、応答に毒性が含まれる場合にチェックして修正する自動プロセスを設定できることを知っておくと安心です。 利用可能なリージョンと料金 Amazon Comprehend Toxicity Detection は、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シドニー) の AWS リージョン で使用できます。 毒性検出を使用する場合、長期間のコミットメントはありません。支払いは、入力文字数の 100 文字単位 (1 単位 = 100 文字) で行い、リクエストあたりの最低料金は 3 単位 (300 文字) です。詳細については、 Amazon Comprehend の料金表を参照してください。 毒性検出を活用してオンラインコミュニティの安全性を向上させ、アプリケーションへの LLM の採用を簡素化してください。 – Danilo 原文は こちら です。

こんにちは、カスタマーソリューションマネージャー (CSM) の服部です。 前編 の記事でEBA (Experience-Based Acceleration) がどんなものか全体イメージをつかんでいただけたと思いますので、後編ではEBAの最後の3日間でおこなうビルド＆デプロイについて詳しくお話させていただきます。ここまでの5週間で準備してきたものをこの3日間で形にする際に、どういったタイムスケジュールでどのようにビルド＆デプロイを行っていくのかについて理解していただければと思います。 ５週間にわたりファシリテーションを担当するチームと開発作業を担当するチームに分かれて準備を進めてきた最後の6週目にデモを作成する３日間が設定されています。この３日間は参加者が一同に会して作業に集中する期間になりますので、普段の業務から離れてビルド＆デプロイに集中していただくことになります。詳細なタイムテーブルは以下に記載しています。朝会と作業、昼会と作業のセットを５回繰り返すタイムテーブルで進めていきます。通常のスプリントは２週間ですが、EBAではそれを３日間に凝縮して実施する形になります。このスプリントの中で最小限のプロダクトを完成させて、最後にエクゼクティブに対してデモを実施してフィードバックをもらいます。   このスプリント経験を通して実際のモダナイゼーション開発の流れを経験していただくことになります。 次に参加者の体制ですが、これまでの準備期間と同じように大きく分けてファシリテートを行うコマンドセンターと実際に開発を行う開発チームの２つのチーム体制で３日間のタイムスケジュールを進めていただきます。チーム分けに際してどういった方をアサインすべきかについて以下にひとつのサンプルを記載しています。コマンドセンターは、メンバー間の調整役を担っていただきメンバー間の連携を強化していただきますので、プロジェクト管理の経験者、進捗管理、問題解決の経験が豊富な方で開発チームからエスカレーションされた事項に対して、判断を下せる権限のある方がアサインされると良いです。また、アジャイル開発は未経験の場合でもウォーターフォールのプロジェクトマネジメント経験が豊富でこの機会にチャレンジしたいマインドがある方がアサインされても問題ありません。作業チームに関しては、作業をしていただく方がアサインされますので、AWSの基本スキルが必要で対象のインフラ、アプリが理解できてることが必須になります。 EBAのAWS支援領域ですが、このプログラムはあくまで伴走支援のため主体はお客様になります。AWSはアドバイスやレビューをしますが何か作るということはしません。トレーニングや座学ではありませんので、前述のように参加メンバーには必要なスキルが定義されています。 モダナイゼーションEBA実施に適しているお客様には２つのパターンがあります。１つ目はAWSをすでに利用しているもののEC2がメインでマネージドサービスやサーバーレスなどクラウドネイティブなサービスを使ってまだアプリケーションを構築したことがない状況のお客様です。２つ目は対象がまだオンプレにあってクラウド移行時に合わせてモダナイズしたいと考えているが、経験がないのでAWSに伴走支援してほしいというお客様になります。この２つの状況に当てはまるお客様はEBAの効果が大きいので是非AWSへお問い合わせいただきEBAの実施をしていただきたいと思っております。 最後にEBAを実際に実施された 弥生株式会社様の事例を紹介させていただきます。 ご紹介するお客様は市場の変化に柔軟に対応できる製品開発サイクル実現のために組織を変革 (アジャイル開発対応) し、顧客の声をもとに改善できる製品設計 (マイクロサービス) をする必要性を感じておられましたが、いわゆるウォーターフォール型の開発に慣れていることで変化の激しいサービスを開発できる体制ができていない状態でした。お客様はAWS 利用経験のある技術者が多くいる状態で自力で変革できる可能性もありましたが、AWSがパイロット開発を約6週間短期集中支援する本EBAの実施を決定されて以下の開発スコープを３つ設定されました。 ・参加者全員が各自の役割を果たし実体験を得ること ・開発プロセスを確立させ動くものをデプロイできること ・スクラムによる開発スプリントを自分たちで回せるようになること また本番を想定した開発プロセスをまわして改善ポイントを見つけることをビルド＆デプロイ期間の目標としてEBAを実施いただいた結果、EBAを通して4回のスプリントを経験され、その中でアジャイル開発のプロセスを体験するのみならずマイクロサービスアーキテクチャなどの開発生産性を高める仕組みも導入してプロセスの改善も実施されました。3日間のビルド＆デプロイ期間でCI/CD Pipelineの構築も行ったことでEBA実施後にも活用できる経験もされました。 これらの経験を当初の課題を解決する足掛かりとしていただくことで、EBA実施の効果を最大化していただけるものと考えております。 こちらのお客様の事例は、“ 技術的負債との戦い、マイクロサービスとアジャイル開発への挑戦 ”に詳しく記載されておりますので是非ご覧ください。 まとめ 前後編に渡って「EBAとは何か」についてご説明させていただきました。EBAの概要、実施目的をご理解いただけましたでしょうか。経験不足などでモダナイゼーションの一歩を踏み出すのが難しい状況におられるお客様は、EBA実施を通して伴走支援させていただきますのでAWSへお問い合わせください。 著者 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 服部 昌克、宮本 雅勝 参考リンク モダナイゼーションを実践するEBA (前編) 技術的負債との戦い、マイクロサービスとアジャイル開発への挑戦 弥生×AWS×モダナイゼーション

こんにちは、カスタマーソリューションマネージャー (CSM) の宮本です。この記事では、モダナイゼーションを検討しているお客様向けに、AWSがご提供するEBA (Experience-Based Acceleration) というプログラムをご紹介します。 以前、 こちらの記事 で、モダナイゼーションとは何か、およびEBAの概要について言及しました。EBAに興味を持たれた方の中には「まだまだ具体的に何をするのかイメージがつかない」という方もいらっしゃると思います。 本記事では、前後編に渡り、より具体的にEBAの内容をご説明し、イメージをつかんでいただきたいと思います。 前編では、EBAの概要、スケジュールや期待される効果、目標設定についてご紹介します。 EBAの概要 EBAは、お客様のモダナイゼーションを加速させるModernization Accelerator (ModAx) というプログラムの一部です。ModAxでは、システムの評価とアーキテクチャ策定を行い、モダナイゼーション対象となるアプリケーションを見極め、実際にビルド＆デプロイを経験していただきます。このビルド＆デプロイを経験いただくプログラムが、EBAです。 なお、システムの評価とアーキテクチャ策定は、MODAというプログラムにて実施します。 MODAとEBAは共に、AWS ITトランスフォーメーションパッケージ for Cloud Nativeとしてご提供しております。詳細は こちらの記事 を参照ください。 また、EBAはモダナイゼーションに限らず、基盤構築やマイグレーションをテーマに実施する場合もありますが、本記事中で言及する”EBA”は、”モダナイゼーションをテーマとしたEBA”の事を指します。 EBAとは、お客様自身によるパイロット開発を伴走型で支援するプログラムです。 本格的なモダナイゼーションの実現に向け、お客様が行うパイロット開発を、約6週間で設定し、“2 pizza team”や“2-way door”という要素も取り入れながら、AWSが短期集中的に支援し、最小プロダクトを開発いただく経験を通して、今後のお客様の開発に役立てていただきます。 “2 pizza team”や、“2-way door”というのは、Amazonで用いられている考え方です。これらの用語は、関連記事である“ アプリケーションのモダナイゼーションを加速するEBA ”で触れていますので参照ください。 スケジュールや期待される効果 EBAは、5週間の準備期間と、6週目の3日間で実施するビルド＆デプロイで構成されています。準備期間では、EBAの目標、成功条件を定義、具体的なタスクを決定し、要件定義・設計・実装を進めていきます。最後の3日間では、参加者が一同に会し、集中的にビルド＆デプロイの作業を実施し、最小限のプロダクトを完成させ、アプリケーションのモダナイゼーションを実践していただきます。 自ら手を動かしてモダナイゼーションを実践し、ノウハウと成功体験を獲得すると同時に、何が不足しているかを把握し、課題を整理することで、今後、お客様が本格的に取り組んでいくモダナイゼーション計画の策定に役立てていただくことを期待しています。 EBAに参加いただく方は、ある程度AWSのサービスに精通している必要があります。 そのため、EBAを実施するうえで必要な知識、スキルが不足している場合、事前にAWSが提供するトレーニングを受講いただく事を推奨します。また、AWSチームによる勉強会を開催する事も可能です。EBAの準備期間に入る前に、必要最低限の知識、スキルを習得いただきます。 では、スキルも習得したところで、5週間の準備期間で何を実施するかを紹介します。 EBAではお客様とAWSとで複数のチームを構成します。 大きくは、ファシリテーションを担当するチームと、実作業を担当するチームに分かれます。ファシリテーション担当は1チームのみですが、作業担当チームは規模に応じて確定させます。ファシリテーション担当チーム、作業チームに対して、AWSチームがそれぞれサポートをさせていただきながら、EBAを進めていきます。 目標設定 最初に、EBAの目標を明確にします。EBAの期間は6週間と限られています。そのため、EBAを何のために実施するのか、何を達成すれば成功とするのか、という具体的な目標を設定し、それを達成するために準備期間で必要なタスクを進めていきます。 目標設定は、非常に重要なポイントであり、同時にお客様が悩まれるポイントです。 EBAに参加する全員が、何を達成すべきなのかを明確に理解できる目標を設定することが重要です。目標があいまいな場合、EBA参加者によって、何を達成するかの基準がずれる可能性があります。EBAでは、2つの観点で目標を設定します。1つは、EBAを実施すること自体の目標で、成功基準とも表現します。もう1つは、各作業チーム毎の目標です。 まず、重要なのはEBAを実施すること自体の目標 (成功基準) を設定することです。 EBA自体の目標設定のために、なぜEBAを実施することに決めたのか、EBA実施後にどうなりたいか、を改めて考えてみてください。アジャイル開発 (スクラム) を取り入れて開発/リリースのスピードを上げたいのか、AWSの構築スキルやサービス知識を習得して自社で開発する力を身に付けたいのか、異なる部門間の協業により組織の壁を取り除きたいのか、実施する理由や、目指すべき姿はさまざまだと思います。目指すべき姿に合わせた目標 (成功基準) を設定し、EBAにてそれを達成することで、ぜひ次のステップへと繋げていただきたいです。 その後、各作業チームの目標を設定します。 各作業チームが、具体的にEBA期間中に何をするのかを定義しましょう。例えば、「対象システムのプロトタイプを作成する」や、「スキルを向上させる」という目標を設定する場合、プロトタイプは、具体的にどの機能まで実装するかであったり、どのような基準でスキルが向上したことを示すか、という事を明確にし共通認識とすることが重要です。 また、現実的な目標に加えて、ストレッチ目標を設定することを推奨します。 「ストレッチ目標」とは、もう少し頑張れば、実現できる程度の難易度に設定された目標のことです。 皆さま、EBAの準備期間開始時のスキルや知識を前提に目標を立てられますが、実際に準備期間を進めていくと、スキルや知識を習得していき、準備期間中に最初に設定した目標を達成することも起こり得ます。最初の時点で、少し高めの目標を設定し、さらに「ストレッチ目標」を設定しましょう。 まとめ 前編ではEBAの概要、スケジュールや期待される効果、目標設定について説明しました。 後編では、最後の6週目の3日間で何を実施するのか、実施体制やEBAにてAWSが支援する事などについて紹介します。 参考リンク アプリケーションのモダナイゼーションを加速するEBA AWS ITトランスフォーメーションパッケージ 2023 ファミリー（ITX 2023） 著者 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 宮本 雅勝、服部 昌克

AWS re:Invent 2023 は、11 月 27 日から 12 月 1 日まで、ネバダ州ラスベガスで開催されます。これは、AWS が主催する 1 年で最も包括的なイベントであり、AWS について学び、スキルを磨くための最も早い方法です。 この記事では、関心のあるトピックを簡単に見つけられるように、モノのインターネット (IoT) セッションの専用トラックをキュレーションし、整理しました。IoT トラックには、自動車、産業、スマートホーム、ロケーションなどの重点分野があります。Innovation Talk と Breakout Session は、AWS のオピニオンリーダーによる講義形式で、多くの場合顧客スピーカーが出演し、他の企業の同僚から直接話を聞くことができます。Chalk Talk、Workshop、Builders’ Session は、よりインタラクティブで技術的で実践的な内容で、AWS の技術専門家が主導します。 また、 Expo 内の AWS Village、開発者ラウンジ、Industries Pavilion を訪れて、AWS IoT の専門家と会話を始めたり、IoT サービスを紹介するデモを見たりすることもできます。 Innovation Talk クラウドテクノロジーがビジネスの推進にどのように役立つかを深く掘り下げる AWS リーダーとのセッションは必見です。 AUT207-INT | クラウドにおける製造とモビリティの革新 HYB207-INT | Innovation Talk: 新興技術 IoT セッション: クロスインダストリー どの業界で働いていても、これらのセッションに参加すると、中核となる IoT サービス、発表、ユースケースについて学ぶことができます。 Breakout Session IOT211 | AWS IoT でビジネスを革新し、顧客体験を高める Chalk Talk IOT101 | Amazon Kinesis Video Streams でエッジにある多数の IP カメラを管理する IOT209 | IoT 接続: パフォーマンス、コスト、統合のバランス IOT301-R | すべての IoT ソリューションの安全な基盤を構築する方法 [再演あり] IOT307 | IoT ソリューションの負荷テストを効果的に行うための戦略 Workshop IOT205 | 生成系 AI と AWS IoT を使用して、絵を描く 2D ロボットを構築する IOT311 | IoT データの取り込みと視覚化のためのアーキテクチャパターンを構築 Builders’ Session IOT304-R | AWS IoT と AI/ML による自動動画モニタリングシステムを構築 [再演あり] IoT セッション: 自動車 これらのセッションに参加して、AWS IoT が安全な車両接続の確立と車両データの効果的な管理にどのように役立つかを学びましょう。 Breakout Session IOT204 | AWS IoT によるコネクテッドカープラットフォームの革新と最新化 Chalk Talk IOT210 | AWS IoT によるコネクテッドカーからのビッグデータワークロードの管理 IOT309-R | MQTT 5 で AWS IoT Core を使用したアプリケーションの革新 [再演あり] Workshop IOT305 | AWS IoT を使用して車両全体の EV バッテリーの異常を検出しよう IoT セッション: インダストリアル これらのセッションに参加して、エッジからクラウドまで優れた運用を実現する最新の産業用データアーキテクチャの設計に AWS IoT がどのように役立つかをご覧ください。 Breakout Session IOT206 | AWS での IoT による産業変革の加速 Chalk Talk IOT212 | AWS IoT SiteWise によるデータヒストリアンのモダナイゼーション IOT310-R | AWS でデジタルツインを 60 分で構築する方法をわかりやすく解説 [再演あり] Workshop IOT203-R | スマート製造のための自動異常検出 [再演あり] IoT セッション: スマートホーム これらのセッションに参加して、AWS IoT が Matter、Amazon Sidewalk、AI などの新しいテクノロジーや仕様を取り入れ、費用対効果が高く、将来を見据えたスマートホームソリューションを構築するのにどのように役立つかを学んでください。 Breakout Session IOT207 | AWS IoT を活用した次世代のスマートホームソリューション IOT213 | AWS IoT によるコネクテッドプロダクトとソリューションのスケーリング Chalk Talk IOT306-R | 生成系 AI を使用した AWS IoT GreenGrass コンポーネントの設計 [再演あり] Workshop IOT202 | 規格に準拠した安全なコネクテッド製品を AWS IoT で構築する IOT302-R | 新しいスマートホームユニバース: Matter規格でIoT製品を設計する [再演あり] IoT セッション: ロケーション これらのセッションに参加して、AWS IoT と Amazon Location Service を一緒に使用して、アセットトラッキング、モバイルエクスペリエンス、ルート最適化などの分野で機能を強化する方法を学びましょう。 Breakout Session IOT208 | 位置情報サービスによる顧客体験の最適化 Chalk Talk IOT308 | AWS IoT と Amazon Location Service でロジスティクストラッキングを最適化する Workshop IOT303 | ロケーションベースのサービスと Amazon Sidewalk を使用したアセットトラッキング Expo Expo では、楽しんだり、AWS の専門家と話したり、テクノロジーのデモを直接見たりすることができます。Expo エリアは広大で、誰もが楽しめるものが揃っています。時間をかけてできるだけ多くのことを見てください。ただし、IoT に注目したい場合は、次の推奨事項を確認してください。 AWS Village — 新技術キオスク 新しいテクノロジーキオスクを訪れて、IoT、ロボティクス、量子に関するデモをご覧ください。IoT デモは、AWS DeepRacer ハードウェアのカスタマイズされたバリエーションで、さまざまな接続テクノロジー (Cellular LTE/NB-IoT、Wi-Fi、LoRaWAN) を紹介し、Alexa、Amazon Sidewalk、Amazon Location Service との相互統合を紹介します。AWS DeepRacer IoT デモでは、さまざまな業界のエッジにおける AWS IoT の変革の可能性を探ります。組織が AWS IoT Greengrass を使用して、コネクテッドカー、スマートシティ、農業などのシナリオでエッジコンピューティングの力を引き出す方法を示しています。AWS IoT at the Edge が、インテリジェントでスケーラブルな機能をネットワークのエッジにもたらすことで、組織が物理世界とデジタル世界のギャップを埋めるのにどのように役立つかをご覧ください。 開発者ラウンジ — Open Source Auto: Vegas Edition 魅力的でインタラクティブな自動車運転のデモを体験してください。このデモでは、車両の状態の監視から車内体験の向上まで、ほぼすべてのユースケースで AWS がどのように車両データの価値を引き出すことができるかを紹介しています。リアルなタッチスクリーンダッシュボード、ステアリングホイール、ペダル、バケットシートを備えた自動車用コックピットの運転席に足を踏み入れます。シミュレーターを使用して、街灯、曲がり角、障害物、ライブトラフィックを備えた仮想都市景観の道路をナビゲートします。ステアリング、ブレーキ、加速中に、車両の CAN 信号やさまざまなセンサーデータをほぼリアルタイムで監視しながら、実行中のアプリケーションプロセスを把握できます。AWS IoT FleetWise、AWS IoT Core、AWS IoT Greengrass など、最新の AWS IoT サービスと機能がすべて実際に動作しているのがわかります。この魅力的なデモは、単なるシミュレーションではありません。コネクテッドカー技術の未来と、自動車の監視と分析の可能性を垣間見ることができます。 Industries Pavilion — 自動車 コネクテッドモビリティ — Connected Mobility Solution on AWS は、コネクテッドカーインフラストラクチャを開発、デプロイ、管理する際のわずらわしさ、時間、コストを削減するように設計された環境をお客様やパートナーに提供するプラットフォームエンジニアリングサービスです。AWS IoT Core などの AWS サービスや、専用の自動車サービスである AWS IoT FleetWise を使用して革新的なソリューションを構築する方法をご覧ください。 OCPP 準拠の大規模な EV 充電 — 化石燃料から電気自動車への移行は、正味ゼロ排出量を達成するための政府および商業公約の重要な要素です。チャージポイントオペレーター (CPO) は、定期的なリモートおよびオンサイトメンテナンス、ヘルスメトリックの収集、運用構成の管理を担当します。AWS IoT Core、Amazon Elastic Container Service、AWS Lambda などのサービスを使用して、EV 業界標準である OCPP に基づいて、スケーラブルで低レイテンシーの CPO ソリューションを構築する方法をご覧ください。お客様は、AWS のマネージドサービスによって、大規模な EV 料金の運用に関連する手間のかかる作業がどのように軽減されるかを学ぶことができます。 Industries Pavilion — 製造 スマート製造 | スマート製造による運用上の洞察の促進 — Amazon スマート製造のデモでは、目視検査、材料トレーサビリティ、状態ベースモニタリング、クラウド主導の自動化を実証する産業サービス (産業用 IoT と機械学習) とソリューション (産業データファブリック) 向けの AWS を紹介します。デモには、リニアトラック、ピックアンドプレースロボット、目視検査カメラが含まれています。これらは、AWS の産業用オートメーション機器を使用して、AWS Snowcone 上で稼働する産業用エッジを介して統合されます。 機械学習 | 機械学習による産業オペレーションの最適化 — このデモでは、お客様が異常な状態 (異常振動) を起こし、Amazon Monitron ワイヤレスセンサーが振動データを Monitron Gateway と AWS に送信するのを見ることができるモーターを取り上げます。Amazon Monitron アプリケーションを通じて、異常なモーター状態に関するアラートが届くのを確認でき、アクションを起こすのがいかに簡単かを知ることができます。さらに、品質検査とコンピュータービジョン (CV) がどのように品質検査を自動化できるかを紹介します。 生成系 AI | 製造業向けの生成系 AI アプリケーションの構築 — 産業企業は、革新的な新製品設計の開発、かつてないレベルの製造生産性の向上、サプライチェーンアプリケーションの最適化など、生成系 AI を活用してビジネスを変革する方法を模索しています。アマゾン ウェブ サービスにより、メーカーが基盤モデルを使用して生成的な AI ベースのアプリケーションを簡単に構築およびスケーリングできるようになった様子を示すデモをご覧ください。 まとめ re:Invent 2023 に皆様をお迎えし、最新のニュースやイノベーションを共有できるのを楽しみにしています。 re:Invent のウェブサイト で詳細を確認し、 フルセッションカタログ をご覧ください。近いうちにお会いしましょう！ この記事は Olivia Bias によって書かれた Get connected with AWS IoT at re:Invent 2023 の日本語訳です。この記事はソリューションアーキテクトの岡本晋太朗が翻訳しました。

この記事は Announcing remote cache support in Amazon ECR for BuildKit clients (記事公開日 : 2023 年 10 月 24 日) の翻訳です。 この機能は、 バージョン 25.0 のリリース 時に Docker によってプリインストールされ、サポートされる予定です。この機能は、Buildkit バージョン 0.12 以降ですでにリリースされており、現在は Finch バージョン 0.8 以降で利用可能です。 導入 Amazon Elastic Container Registry (Amazon ECR) は、お客様がコンテナイメージとアーティファクトを保存、共有、デプロイするために使用する、完全マネージドなコンテナレジストリです。Amazon ECR は、AWS 環境と非 AWS 環境の両方で、お客様のビルドとデプロイのパイプラインの一部として、数十万人のお客様によって使用されています。 お客様が Amazon ECR や他のレジストリで最も頻繁に作業するのは、コンテナイメージのパッケージ化とレジストリへの保存を担当するコンテナクライアントです。これらの多くのクライアントは、 BuildKit として知られる一般的なオープンソースのイメージビルドツールキットを使用しています。これには、 Docker (23.0 以降)、 Finch 、 Earthly などのクライアントが含まれます。ビルド時に、クライアントはコンテナイメージの各レイヤーを、イメージが完成するまで 1 つずつビルドします。 一部のレイヤーはビルド間であまり変更されないため、クライアントはビルドしたすべてのレイヤーのローカルコピーを保存し、その後のビルドでこのローカルキャッシュを再利用します。これは、毎回レイヤーを再ビルドするよりもはるかに高速です。 ただし、これはビルドランナーまたはワーカーが各ビルド実行ごとに同じコンピュート環境で実行される場合にのみ機能します。 GitHub Actions や GitLab CI Enterprise などの一般的な CI/CD プラットフォームは、ビルドごとに一時的なコンピュートを使用するため、ローカルキャッシュを構築および使用することができません。 ソリューションの概要 一時的なコンピュートツールでもキャッシュを使用できるようにするために、 BuildKit は 2020 年にリモートキャッシュをエクスポートする機能を導入しました。 これらのリモートキャッシュは、ローカルのレイヤーキャッシュと同様に機能します (つまり、レイヤーは格納され、スクラッチから再構築する代わりに使用されます) 。 唯一の違いは、ビルドされた各レイヤーがリモートレジストリに送信され、後続のビルドでローカルキャッシュにない場合に取得されることです。 AWS のお客様は、この機能を使用してイメージのビルドを速めることを望んでおり、 Amazon ECR でのサポートを求めていました。 ただし、これらのキャッシュを格納するために使用されるフォーマットは、 Open Containers Initiative (OCI) 形式ではありませんでした。 Amazon ECR は OCI 準拠のレジストリであるため、このリモートキャッシュフォーマットを Amazon ECR にプッシュすると、検証に失敗します。 BuildKit は最近バージョン 0.12 をリリースしました。このバージョンには、リモートビルドキャッシュを OCI 互換の方法で生成および保存できるソリューションを提供しています。これには Amazon ECR エンジニアからの貢献 が含まれています。これは、 BuildKit が Amazon ECR のように OCI 仕様を実装するレジストリでビルドキャッシュを保存および取得できることを意味します。このアップデートにより、ビルドおよびプッシュされたイメージとは別に、キャッシュイメージを Amazon ECR リポジトリにプッシュできるようになります。このキャッシュイメージは、後のビルドで参照でき、ノート PC からのプッシュか、 GitLab や GitHub Actions などのプラットフォーム上の本番 CI/CD ビルドからのプッシュかに関わらず、プッシュ時間を大幅に短縮することができます。 ウォークスルー Amazon ECRでのリモートキャッシュの使い方 これらの例では、 Docker を使用します。バージョン 25.0.0 以降を実行していることを確認してください。これには、 Amazon ECR やその他の OCI 互換レジストリで機能するために必要な変更が含まれている BuildKit 0.12 が含まれています。これらの例は、ローカルの開発環境で実行するか、 CI/CD プラットフォームのビルドスクリプトで使用できます。 例えば次のようにして、 CI/CD には Docker を使用してイメージをローカルでビルドし、その後ビルドしたイメージを Amazon ECR にプッシュするビルドステップをおこないます。 docker build -t <account-id>.dkr.ecr.<aws-region>.amazonaws.com/buildkit-test:image . docker push <account-id>.dkr.ecr.<aws-region>.amazonaws.com/buildkit-test:image Apache Configuration Amazon ECR にキャッシュを入力し、その後のビルドで使用するようにするには、ビルドコマンドに –cache-to および –cache-from オプションを追加します。 docker build -t <account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:image \ --cache-to mode=max,image-manifest=true,oci-mediatypes=true,type=registry,ref=<account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:cache \ --cache-from type=registry,ref=<account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:cache . docker push <account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:image Apache Configuration 一見多くの設定があるように見えますが、追加したことを順を追って見ていきましょう。 cache-to と cache-from という 2 つの新しいオプションセットがあります。 cache-to オプションは、 ref という引数のコンテキストキーで指定されたイメージ URI に基づいて、エクスポート先(または作成先)のリモートキャッシュを指定します。ここでのイメージ URI は、実際にビルドされているタグ付きイメージとは異なることに注意してください。必要に応じて、キャッシュの URI を Amazon ECR の別のリポジトリを指すように設定できますが、これは必須ではありません。 type という引数のコンテキストキーで指定された値 registry は、レジストリにプッシュするリモートキャッシュを作成していることを意味します。 Buildkit 0.12 で導入された新しいコンテキストキーは image-manifest です。このキーの値を true に設定すると、レジストリに OCI 互換バージョンのリモートキャッシュを保存できるようになりました。また、 image-manifest を使用するには oci-mediatypes を true に設定する必要があるため、それも設定しています。リモートキャッシュは ref のイメージ URI で暗黙的にプッシュされるため、ビルドステップに別の push コマンドを追加する必要はありません。 cache-from オプションは、Dockerfile で特定のビルドステップを実行する代わりに BuildKit が取得できるキャッシュの場所を指定します (ただし、そのレイヤーとそれ以前のレイヤーについて 何も変更されていない場合 )。この場合、cache-to で指定したキャッシュマニフェスト URI を持つ Amazon ECR リポジトリから取得されます。 要約すると、 cache-to はリモートキャッシュマニフェストをエクスポートし将来のビルドを高速化するための準備をするものであり、 cache-from はエクスポートされたリモートキャッシュマニフェストを利用して、現在のビルドを高速化します。キャッシュが最初に存在しない場合、 cache-from は諦めてキャッシュを使用しないため、新しいビルドステップに両方を同時に導入できます。この 1 つの変更により、レイヤーが変更されるたびに新しいビルドがリモートキャッシュを更新し、すべてのビルドが常に最新のキャッシュを使用します。 このビルドを実行して AWS コンソールに移動し、 Amazon ECR にプッシュされた内容を確認してみましょう。 イメージとキャッシュがあることがわかります。後続のビルドでは、 Dockerfile のキャッシングのベストプラクティス に従うビルドの場合、イメージのビルドステップがかなり速くなるはずです。 CI/CD ソリューションを最新バージョンの Docker または BuildKit にアップデートする方法については、 CI/CD プロバイダーのドキュメントを参照してください。代表的な CI/CD ソリューションのアップデート方法の例を紹介します。 GitLab CI の場合 GitLab Runner の docker image の tag を最新バージョンの dind に簡単に変更できるはずです。 GitHub Actions では、 setup-buildx-action を、バージョンが最新に設定されているか、バージョン文字列が 0.12 以降に設定されていることを確認してください。 Travis CI の場合は、 こちら から Travis インストレーションを更新できます。 CircleCI の場合、yml の setup_remote_docker にあるバージョンを、 こちら に示されているサポートされている最新のバージョンに変更できるはずです。 まとめ このブログ記事で説明したソリューションを使用すると、 Amazon ECR にリモートビルドキャッシュを保存することでコンテナのビルドを高速化できます。私たちの信条は、 AWS のお客様だけでなく、 OCI のようなオープンソースコミュニティや標準にも適したソリューションを提供することです。 Amazon ECR では、 BuildKit へのサポートの組み込みが、よりオープンで互換性のあるリモートキャッシュソリューションを実現したと考えています。今すぐ CI/CD のビルドパイプラインでリモートキャッシュをお試しいただき、高速で一貫したイメージビルド時間のメリットを体験してください！ 筆者 Matt Kang 翻訳はソリューションアーキテクトの瀧田 直斗が担当しました。原文は こちら です。

2023 年 10 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Control Tower 機能紹介編 統制の効いたマルチアカウント環境を構築する際に AWS Control Tower は有力な選択肢です。AWS Black Belt Online Seminar AWS Control Tower 機能紹介編では、AWS Control Tower の各機能の詳細を紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Control Tower に興味のある方 AWS Control Tower について深く学びたい方 本 BlackBelt で学習できること AWS Control Tower の各機能の詳細 ランディングゾーン コントロール Account Factory スピーカー 桂井俊朗 ソリューションアーキテクト AWS Lake Formation AWS Lake Formation は安全なデータレイクを簡単に作ることができるサービスです。主要な機能としてデータレイクへの一元的なアクセス制御やデータレイクへのデータ投入、クロスアカウントやクロスリージョンでのデータ共有を行うことが可能です。 資料（ PDF ） 対象者 前提知識は、「AWS のグローバルインフラストラクチャやフルマネージドサービスの概念」と「AWS の基盤となるサービスの基本的な知識」です。 対象者は安全なデータレイクを作る上で「AWS Lake Formation」で何ができるのかを知りたい方です。 本 BlackBelt で学習できること AWS Lake Formation の基本的なサービス概要、Lake Formation の仕組み、Lake Formation の各種機能の詳細を解説します。 スピーカー 佐藤祥多 アナリティクススペシャリストソリューションアーキテクト Amazon SageMaker Canvas ノーコードで始める機械学習【ML-Dark-10】 Amazon SageMaker Canvas を利用してノーコードで機械学習を始める方法について解説しました。 資料（ PDF ） | 動画（ YouTube ） 対象者 まだ機械学習の知識・スキルはないけど、業務に機械学習を活用したい方 データ分析・機械学習のワークロードを効率化したい方 本 BlackBelt で学習できること Amazon SageMaker Canvas の使い方・使いどころ ビジネス課題へ機械学習を適用するはじめの一歩 既存の ML ワークロードを効率化する方法 スピーカー 小杉知己 プロフェッショナルサービス AWS Application Discovery Service の概要（AWS 移行準備シリーズ） クラウド移行をはじめるには、品質や TCO を考慮しつつ移行プランを作成する等入念な移行準備が必要になります。AWS では、そのための情報を収集する Discovery ツールを提供しています。本セッションでは、そのうちの1つ、エージェントまたはエージェントレス型での情報収集を行う AWS Application Discovery Service をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 移行案件に関わったことのある、これから関わられる方の内、移行を企画・検討中の方、移行プランの策定を行う方、IT 資産の棚卸しを検討中の方、特に、上記に取り組まれる PM 、アーキテクトの方 本 BlackBelt で学習できること Discovery 作業（情報収集）の必要性、および AWS Application Discovery Service の概要 スピーカー 鈴木槙将 ソリューションアーキテクト Amazon Monitron Part 2（設定編） Amazon Monitron は回転機器の振動や温度データを、設備に貼り付けた電源不要のセンサーデバイスでクラウド上へ収集しクラウドで分析することで、潜在的な障害の予兆を検知して、計画外のダウンタイム発生を防止するソリューションです。このセミナーでは Amazon Monitron シリーズ Part 2 として、Amazon Monitron を購入し実際に利用開始する方法を説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 工場、プラント、物流拠点等で設備の計画外ダウンタイムを減らしたい方 モーター・ギア・ベアリング・ポンプ・コンプレッサーなどの回転体部品を多く稼働させておりそれらの点検保守を効率化したい方 機器の計画保守（定期的な点検保守）を減らし、データに基づく予測型保守を導入したい方 Amazon Monitron ( 基礎編）Part1 で Amazon Monitron の仕組みを学んだ方 本 BlackBelt で学習できること Amazon Monitron ( 基礎編）Part1 で Amazon Monitron の仕組みを学んだ方向けに、今回の Part 2 では Amazon Monitron を購入し実際に利用開始する方法を説明します。 スピーカー 伊藤ジャッジ向子 ソリューションアーキテクト Amazon EventBridge グローバルエンドポイント この動画では、Amazon EventBridge のグローバルエンドポイントの機能について紹介します。本機能を使用することで、システムのレジリエンスを向上させ、より堅牢なアプリケーションを開発することが可能になります。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EventBridge について基本的な知識をお持ちの方 システムのレジリエンス向上に興味のある方 Amazon EventBridge を利用したマルチリージョン構成をご検討の方 本 BlackBelt で学習できること EventBridge グローバルエンドポイントを使用した高可用性アプリケーションの設計・開発方法 スピーカー 櫻谷広人 パートナーソリューションアーキテクト Amazon Connect カスタム CCP による従業員体験の向上 Amazon Connect では、公開している API を使用してお客様がソフトフォンを自由にカスタマイズ可能です。本セッションはコンタクトセンターにおける様々な課題のうち従業員体験の課題にフォーカスし、技術的な解決方法としてサンプルのカスタムソフトフォンをご紹介し、アーキテクチャを詳細に解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect カスタム CCP の具体的な実装例を知りたい方 フロントエンド/バックエンド開発の基本的な知識のある方 本 BlackBelt で学習できること Amazon Connect のエージェントインタフェースを拡張するための実装方法、および Amazon Connect のメトリクスを取得する際の注意点について学習できます。 スピーカー 清水幸典、小柳ちか子 Amazon Connect スペシャリスト ソリューションアーキテクト、プロトタイピングエンジニア Amazon Connect Google Chrome サードパーティ Cookie の段階的廃止に関する対応 Google 社のプライバシーサンドボックスの取り組みの一環として、Google Chrome にてサードパーティ Cookie を段階的に廃止する計画が発表されました。このセミナーでは、Amazon Connect で Chrome を継続的にご使用頂くために必要な対応について説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect をご利用中のエンドユーザー様、パートナー様 Amazon Connect でカスタム CCP に関する基本的な知識や開発経験をお持ちの技術者 本 BlackBelt で学習できること Chrome のサードパーティ Cookie 廃止に伴いカスタム CCP や CTI Adapter において必要な対応および注意点 スピーカー 梅田裕義 ソリューションアーキテクト Amazon EC2 Auto Scaling スケーリングポリシーとおすすめ機能編 Amazon EC2 Auto Scaling の活用編として、スケーリングポリシーとおすすめ機能についてご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 基盤環境のインフラを担当されている方 EC2 インスタンスの自動スケールと管理に必要な知識を知りたい方 本 BlackBelt で学習できること Auto Scaling サービス群の整理、令和におすすめのスケーリングポリシー、よくあるご質問をご紹介します。 スピーカー 滝口開資 シニアスペシャリストソリューションアーキテクト AWS CloudFormation DeepDive 編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、リソースをモデル化、プロビジョニング、管理することができます。 本セミナーでは、AWS CloudFormation を活用する上で有効な機能について紹介していきます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation の深い機能を知りたい方 カスタムリソースやマクロなどカスタム機能について詳細を知りたい方 本 BlackBelt で学習できること カスタムリソースやマクロといったカスタム機能の詳細 スタックやリソースの保護に関する機能 AWS CodePipeline と組み合わせた構成例 スピーカー 山本一生 クラウドサポートエンジニア AWS CloudFormation CloudFormation レジストリ編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、リソースをモデル化、プロビジョニング、管理することができます。 本セミナーでは、CloudFormation レジストリの概要や機能、実装について解説いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 CloudFormation レジストリに興味のある方 CloudFormation 上で独自に実装したロジックを実行されたい方 本 BlackBelt で学習できること CloudFormation レジストリの概要や機能 CloudFormation に対応したリソースの実装方法 スピーカー 山本一生 クラウドサポートエンジニア AWS CloudFormation よくあるユースケースと質問編 AWS CloudFormation の よくあるユースケース別の使い方や質問について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 本セミナーでは、AWS CloudFormation の ユースケース や よく聞かれる疑問に興味のある方 AWS の基本的な概要や操作、AWS CloudFormation の用語について理解している方 本 BlackBelt で学習できること よくあるユースケースとして、手動で作ったリソースの CloudFormation の管理化に入れる方法や CloudFormation テンプレートの分割方法、複数の AWS アカウントやリージョンに基本設定を展開するなどの様々な例を取り上げて解説します。 スピーカー 木村友則 ソリューションアーキテクト AWS Budgets AWS Budgets を使用すると、想定外の料金の増加にいち早く気付くことができます。 AWS Budgets を使用した予算、予算レポートのポイント、設定方法をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 料金の予算管理をしたい方 AWS 料金の想定外の増加にいち早く気付きたい方 AWS 料金の予測することにより、既存の計画の改善をしたい方 本 BlackBelt で学習できること AWS Budgets の概要と基本的な使い方 AWS Budgets Report の概要と基本的な使い方 AWS Chatbot を使用したチャットツールとの連携方法 スピーカー 岡本迅人 シニアテクニカルアカウントマネージャ Amazon CodeCatalyst Overview 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Overview 編では、Amazon CodeCatalyst の全体像を解説します。 資料（ PDF ）  対象者 チーム開発をするすべてのアプリケーション開発者 Amazon CodeCatalyst の全体像を理解したい方 本 BlackBelt で学習できること Amazon CodeCatalyst のメリット Amazon CodeCatalyst の機能と概念 Amazon CodeCatalyst の料金 スピーカー 三尾泰士 ソリューションアーキテクト Amazon GameLift FleetIQ Amazon GameLift FleetIQ は、セッションベースのオンラインマルチプレイヤーゲームの専用ゲームサーバーをホスティングする AWS サービス Amazon GameLift に含まれる、専用ゲームサーバー向けに Amazon EC2 と Amazon EC2 Auto Scaling の活用を最適化するホスティングオプションです。 本セミナーでは、Amazon GameLift FleetIQ の概念と統合方法について体系的に解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 柔軟性の高い専用ゲームサーバーホスティングサービスを検討されている方 既存の専用ゲームサーバーを AWS でホスティングしたい方 Amazon GameLift FleetIQ の導入予定・検討中の方 本 BlackBelt で学習できること Amazon GameLift FleetIQ の概念と統合方法 スピーカー 安藤怜央 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-11 Amazon Linux 最新情報 ソリューションアーキテクト 寺部祐菜 2023-11 Karpenter Basic ソリューションアーキテクト 多田慎也 2023-11 AWS SAW – セルフサービス自動化ランブックを使用したトラフィック監視の視覚化 Amazon Virtual Private Cloud (Amazon VPC) 編 クラウドサポートエンジニア 中村佑希 2023-11 AWS CloudFormation#2 基礎編 クラウドサポートエンジニア 上原優樹 2023-11 AWS CloudFormation 開発・テスト・デプロイ編 ソリューションアーキテクト 山川達也 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service (Amazon EKS) 編 クラウドサポートエンジニア 坂元龍太 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud – Windows 編 クラウドサポートエンジニア 和田智優 2023-11 Amazon CloudWatch Evidently テクニカルアカウントマネージャー 日平大樹 2023-11 AWS SAW – Nitro システムへの移行を支援する SAW ランブックのご紹介（EC2 Linux 編） クラウドサポートエンジニア 渡邉亮藏 2023-11 AWS SAW – セルフサービスなトラブルシューティング Amazon S3 + AWS Lambda 編 クラウドサポートエンジニア 石川直哉 2023-12 Amazon DynamoDB: Under the hood ソリューションアーキテクト 堤勇人 2023-12 Amazon CodeCatalyst Dev Environment 編 ソリューションアーキテクト 髙柴元 2023-12 Amazon CodeCatalyst Project 編 ソリューションアーキテクト 堀竜慈 2023-12 Amazon CodeCatalyst Space 編 ソリューションアーキテクト 柳久保友貴 2023-12 Amazon CodeCatalyst Workflow 編 パートナーソリューションアーキテクト 田中 創一郎 2023-12 Amazon CodeCatalyst Issues 編 ソリューションアーキテクト 江口昌宏 2023-12 Amazon MemoryDB Overview ソリューションアーキテクト 堤勇人 2023-12 モダナイゼーションプロジェクト立ち上げのポイント ソリューションアーキテクト 平岩梨果 2023-12 Amazon DataZone Overview ソリューションアーキテクト 平井健治 2023-12 移行戦略 (7R) の概要（AWS 移行準備シリーズ） テクニカルインストラクター 杉山大夢 2023-12 AWS への大規模移行のための戦略とベストプラクティス カスタマーソリューションマネージャー 大熊正浩

AWS Health の新機能を発表し、AWS リソースの計画されたライフサイクルイベントを管理し、チームがリソースレベルで実行する完了アクションを動的に追跡して、アプリケーションの円滑な運用を継続できるようにします。計画されているライフサイクルイベントの例としては、 Amazon Elastic Kubernetes Service (Amazon EKS) の Kubernetes バージョンの標準サポート終了、 Amazon Relational Database Service (Amazon RDS) の証明書のローテーション、他のオープンソースソフトウェアのサポート終了などが挙げられます。 これらの機能には以下が含まれます。 アプリケーションの中断を最小限にするために、可能な限りリソースレベルでアクションの完了を動的に追跡する機能。 マイナーな変更については少なくとも90日前、メジャーな変更については可能な限り180日前に通知を使用し、今後予定されているライフサイクルイベントをタイムリーに可視化します。 準備とアクションの実行に役立つ標準化されたデータ形式。AWS Health API を使用して、AWS Health イベントをお好みの運用ツールとプログラムで統合します。 委任された管理者を持つ全社的なワークロードを管理するチームの 計画されたライフサイクルイベントを組織全体で可視化します 。これは、Cloud Center of Excellence (CCoE) チームなどの中央チームが、組織ビューにアクセスするために管理アカウントを使用する必要がなくなったことを意味します。 Amazon EventBridge 上の組織内のすべてのアカウントからの AWS Health イベント の単一のフィード。これは、EventBridge 上でルールを作成してアクションを実行することで、組織全体の AWS Health イベントの管理を自動化するための一元的な方法を提供します。イベントの種類に応じて、イベント情報の取得、追加イベントの開始、通知の送信、是正処置、その他のアクションを実行できます。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどのアップデートがスケジュールされている AWS リソースが AWS アカウントにある場合、AWS Health を使用して、AWS コンソールモバイルアプリケーションに メール、AWS Chatbot、またはプッシュ通知を受け取ること ができます。 仕組み 計画されたライフサイクルイベントは、AWS Health Dashboard、AWS Health API、EventBridge から利用できます。AWS Health 通知を受信したり、作成したルールに基づいてアクションを開始するために、 “source”: [“aws.health”] 値を含む EventBridge 上のルールを作成すること によって、組織全体の AWS Health イベントの管理を自動化できます。例えば、AWS Health が EC2 インスタンスに関するイベントをパブリッシュした場合、これらの通知を使用してアクションを起こし、必要に応じてリソースを更新または置き換えることができます。「 スケジュールされた変更 」タブで、AWS リソースの計画されたライフサイクルイベントを見ることができます。 テーブルビュー – 組織レベル イベントの優先順位をつけるために、予定されている変更をカレンダービューで確認できるようになりました。イベントには、変更がいつ開始されるかを示す開始時刻があります。ステータスは、変更が発生するか、影響を受けるすべてのリソースに処置が施されるまで、「 今後の予定 」のままです。イベントのステータスは、影響を受けるすべてのリソースのアクションが完了したときに「 完了 」に変わります。 注目したくないイベントステータスの選択を解除することもできます。より具体的なイベントの詳細を表示するには、イベントを選択して、画面の右または下に分割パネルビューを開きます。 選択されたカレンダーイベント – 組織レベル（影響を受けるリソース） イベントの詳細表示で「 影響を受けるリソース 」タブを選択すると、影響を受けるリソースを解決するために適切な人々に働きかけるのに役立つ関連アカウント情報を見ることができます。 影響を受けるリソースビュー – アカウントレベル 他の AWS サービスとの統合 AWS Health に既に存在する EventBridge 統合を使用すると、変更イベントとその完全に管理されたライフサイクルを、JIRA、ServiceNow、 AWS Systems Manager OpsCenter などの他のツールに送信できます。EventBridge は、イベントに対するすべての更新（例えば、タイムスタンプ、リソースステータスなど）をこれらのツールに送信し、お好みのツーリングでイベントのステータスを追跡できるようにします。 EventBridge 統合 今すぐご利用いただけます AWS Health の計画されたライフサイクルイベントは、中国と GovCloud リージョンを除く、AWS Health が利用可能なすべての AWS リージョン で利用可能です。 詳細については、 AWS Health ユーザーガイド にアクセスしてください。ご質問は AWS re:Post for AWS Health 、または通常の AWS サポート窓口までお送りください。 — Veliswa 原文は こちら です。

「 データは、あらゆるアプリケーション、プロセス、ビジネス上の意思決定の中心にあります 」と、AWS のデータベース、分析、機械学習担当バイスプレジデントである Swami Sivasubramanian は述べていますが、まったく同感です。お客様が現在使用している一般的なパターンは、データパイプラインを構築して Amazon Aurora から Amazon Redshift にデータを移動することです。これらのソリューションは、売上の増加、コストの削減、ビジネスの最適化に役立つインサイトを得るのに役立ちます。 分析用のデータを準備するのではなく、データから価値を創出することに集中していただけるように、AWS re:Invent 2022 で Amazon Redshift との Amazon Aurora ゼロ ETL 統合を発表し 、2023 年 6 月に Amazon Aurora MySQL 互換エディションの パブリックプレビュー を行うことを発表しました。 一般提供開始: Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合 11月7日、Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合が一般公開されたことを発表しました。このフルマネージドソリューションがあれば、トランザクションデータから時間的制約のあるインサイトを引き出して重要なビジネス上の意思決定を行うために、複雑なデータパイプラインを構築して維持する必要がなくなります。 Amazon Aurora と Amazon Redshift の ゼロ ETL 統合 により、Amazon Redshift のペタバイト単位のトランザクションデータに対して、ほぼリアルタイムの分析と機械学習 (ML) を実行できるようになります。このデータが Aurora に書き込まれると、数秒以内に Amazon Redshift で利用できるようになります。 また、Amazon Redshift の複数の Aurora MySQL データベースクラスターから統合分析を実行して、多くのアプリケーションやパーティションにわたる総合的なインサイトを引き出すこともできます。 Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合により、複数の Aurora データベースからの 1 分あたり 100 万件を超えるトランザクション (1 分あたり 1,750 万件の行の挿入/更新/削除操作に相当) が処理され、それらを Amazon Redshift で 15 秒未満で利用できるようになります (レイテンシーラグ 50 倍)。 さらに、マテリアライズドビュー、リージョン間のデータ共有、複数のデータストアやデータレイクへのフェデレーションアクセスなど、Amazon Redshift の分析機能と組み込みの ML 機能を活用できます。 使用を開始しましょう この記事では、いくつかのステップと、簡単に始めるための情報について説明します。既存の Amazon Aurora MySQL サーバーレスデータベースと Amazon Redshift データウェアハウスを使用します。 まず、Amazon RDS に移動し、 ゼロ ETL 統合 ページで ゼロ ETL 統合を作成 を選択する必要があります。 ゼロ ETL 統合の作成 ページで、いくつかのステップに従って、Amazon Aurora データベースクラスターと Amazon Redshift データウェアハウスの統合を設定する必要があります。 まず、統合用の識別子を定義し、 次へ を選択します。 次のページで、 RDS データベースの参照 を選択してソースデータベースを選択する必要があります。 ここでは、既存のデータベースをソースとして選択できます。 次のステップでは、ターゲットの Amazon Redshift データウェアハウスを尋ねられます。ここでは、自分のアカウントまたは別のアカウントで Amazon Redshift Serverless または RA3 データウェアハウスを柔軟に選択できます。 Redshift データウェアハウスの参照 を選択します。 次に、ターゲットデータウェアハウスを選択します。 Amazon Aurora はデータウェアハウスに複製する必要があるため、リソースポリシーを追加し、Aurora データベースを Amazon Redshift データウェアハウスの承認された統合ソースとして追加する必要があります。 この問題は、Amazon Redshift コンソールで手動で更新するか、Amazon RDS に修正を任せることで解決できます。チェックボックスにチェックを入れます。 次のページでは、Amazon RDS が実行する変更が表示されます。 続行 を選択します。 次のページでは、タグと暗号化を設定できます。デフォルトでは、ゼロ ETL 統合は AWS Key Management Service (AWS KMS) を使用してデータを暗号化します。独自のキーを使用することもできます。 次に、すべての設定を確認し、 ゼロ ETL 統合の作成 を選択して統合を作成する必要があります。 数分後に、ゼロ ETL 統合が正常に作成されました。次に、Amazon Redshift に切り替えると、 ゼロ ETL 統合 ページに、最近作成したゼロ ETL 統合があることがわかります。 統合には、まだ Amazon Redshift 内にターゲットデータベースがないため、ターゲットデータベースを作成する必要があります。 これで統合設定は完了です。このページでは、統合ステータスがアクティブで、複製されたテーブルが 1 つあることがわかります。 テストのために、Amazon Aurora データベースに新しいテーブルを作成し、このテーブルにレコードを挿入します。 その後、Amazon Redshift 内部の Redshift クエリエディタ v2 に切り替えました。ここで、統合の一環として作成したデータベースに接続できます。簡単なクエリを実行すると、データが Amazon Redshift 内ですでに利用可能であることがわかります。 このゼロ ETL 統合は、2 つの理由で非常に便利だと思いました。まず、複数のデータベースクラスターのすべてのデータを統合し、集約して分析できました。次に、トランザクションデータが Amazon Aurora MySQL に書き込まれてから数秒以内に、このゼロ ETL 統合により、Amazon Redshift でシームレスにデータを使用できるようになりました。 留意点 可用性 – Amazon Redshift との Amazon Aurora ゼロ ETL 統合は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) でご利用いただけます。 サポートされているデータベースエンジン – Amazon Redshift との Amazon Aurora ゼロ ETL 統合は現在、Amazon Aurora の MySQL 互換エディションをサポートしています。Amazon Aurora PostgreSQL 互換エディションのサポートは現在進行中です。 価格 –  Amazon Redshift との Amazon Aurora ゼロ ETL 統合は追加料金なしで提供されます。ゼロ ETL 統合の一環として作成された変更データの作成と処理に使用された既存の Amazon Aurora および Amazon Redshift リソースに対してお支払いいただきます。 私たちは、お客様が分析用のデータを準備するのではなく、データから価値を創出することに集中していただけるよう、また一歩前進しています。開始方法の詳細については、 Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合 ページをご覧ください。 統合おめでとうございます! —  Donnie 原文は こちら です。

Amazon Data Lifecycle Manager は、 AWS Systems Manager ドキュメントに埋め込まれたスナップショット前のスクリプトとスナップショット後のスクリプトの使用をサポートするようになりました。これらのスクリプトを使用して、 Data Lifecycle Manager によって作成された Amazon Elastic Block Store (Amazon EBS) スナップショットにアプリケーション整合性があることを確認できます。スクリプトは、I/O 操作の一時停止と再開、バッファリングされたデータの EBS ボリュームへのフラッシュなどを行えます。このリリースの一環として、セルフマネージドリレーショナルデータベースと Windows Volume Shadow Copy Service (VSS) でこの機能の使用方法を示す詳細なブログ記事も公開します。 Data Lifecycle Manager (DLM) のまとめ 簡単にまとめると、 Data Lifecycle Manager は、Amazon EBS ボリュームスナップショットの作成、保持、削除を自動化するのに役立ちます。EC2 インスタンスを AWS Systems Manager にオンボーディングする、DLM 用の IAM ロールをセットアップする、SSM ドキュメントにタグを付けるなどの前提条件となるステップを完了したら、ライフサイクルポリシーを作成し、該当する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを (タグで) 示し、保持モデルを設定して、残りは DLM に任せるだけです。ポリシーでは、スナップショットをいつ実行するか、何をバックアップするか、どれだけの期間スナップショットを保持するかを指定します。DLM の詳細な説明については、2018 年のブログ記事「 新規 – Amazon EBS スナップショットのライフサイクル管理 」をご覧ください。 アプリケーション整合性があるスナップショット EBS スナップショットは Crash-consistent です。つまり、スナップショットが作成された時点の関連付けられた EBS ボリュームの状態を表しています。アクティブなリレーショナルデータベースの状態をキャプチャするためにスナップショットを使用しないアプリケーションを含め、多くの種類のアプリケーションにはこれで十分です。 アプリケーション整合性 があるスナップショットを作成するには、保留中のトランザクション (処理が完了するのを待っている、またはトランザクションが失敗するのいずれか) を考慮し、それ以降の書き込み操作を一時的に停止し、スナップショットを作成して、通常の操作を再開する必要があります。 そして、それが今日のリリースが行われる場所です。DLM は、アプリケーション整合性があるバックアップの準備をするようインスタンスに指示できるようになりました。スナップショット前のスクリプトは、保留中のトランザクションを管理したり、メモリ内のデータを永続ストレージにフラッシュしたり、ファイルシステムを フリーズ させたり、アプリケーションやデータベースを停止させたりすることができます。その後、スナップショット後のスクリプトによって、アプリケーションやデータベースを元の状態に戻したり、永続ストレージからメモリ内キャッシュをリロードしたり、ファイルシステムを解凍したりすることができます。 カスタムスクリプトの基本レベルのサポートに加えて、この機能を使用して VSS Backup スナップショットの作成を自動化することもできます。 前および後のスクリプト 新しいスクリプトはインスタンスの DLM ポリシーに適用されます。スナップショット前のスクリプトとスナップショット後のスクリプトを含む SSM ドキュメントを参照するポリシーを作成し、それが単一のインスタンスに適用されると仮定します。ポリシーをスケジュールに従って実行すると、次のようになります。 スナップショット後のスクリプトは SSM ドキュメントから起動されます。 スクリプト内の各コマンドが実行され、スクリプトレベルのステータス (成功または失敗) がキャプチャされます。ポリシーで有効になっている場合、DLM は失敗したスクリプトを再試行します。 マルチボリューム EBS スナップショットは、インスタンスにアタッチされた EBS ボリュームに対して開始され、ポリシーによってさらに制御されます。 スナップショット後のスクリプトは SSM ドキュメントから起動されます。 スクリプト内の各コマンドが実行され、スクリプトレベルのステータス (成功または失敗) がキャプチャされます。 ポリシーには、いずれかのスクリプトがタイムアウトまたは失敗したときに実行されるアクション (再試行、続行、またはスキップ) を制御できるオプションが含まれています。ステータスはログに記録され、 Amazon CloudWatch メトリクスが公開され、 Amazon EventBridge イベントが発行されます。また、ステータスは各スナップショットに自動的に割り当てられるタグにエンコードされます。 スナップショット前のスクリプトとスナップショット後のスクリプトは、コマンドドキュメントで許可されている任意のアクション ( シェルスクリプトの実行 、 PowerShell スクリプトの実行 など) を実行できます。アクションは、ポリシーで指定されたタイムアウト (10 秒から 120 秒の許容範囲) 内に完了する必要があります。 開始方法 堅牢なスクリプトペアを構築するには、アプリケーションまたはデータベースを詳細に理解する必要があります。すべてがうまくいったときに「ハッピーパス」を処理することに加えて、スクリプトはいくつかの障害シナリオに備えて計画を立てる必要があります。例えば、スナップショット前のスクリプトは、スナップショット後のスクリプトが期待どおりに動作しない場合に備えて、フェイルセーフとして機能するバックグラウンドタスクをフォークする必要があります。各スクリプトは、 こちら で詳しく説明するように、シェルレベルのステータスコードを返す必要があります。 スクリプトを作成してテストし、SSM ドキュメントとしてパッケージ化したら、EC2 コンソールの Data Lifecycle Manager ページを開き、 EBS スナップショットポリシー を選択して、[ 次のステップ ] をクリックします。 本稼働 の モード でタグ付けされたすべてのインスタンスをターゲットにし、デフォルトの IAM ロールを使用し (別のロールを使用する場合は、SSM へのアクセスを有効にする必要があります)、残りの値はそのままにして、次に進みます。 次のページで、[ 前および後のスクリプト ] まで下にスクロールして、セクションを展開します。[ 前および後のスクリプトを有効にする ] をクリックし、[ カスタム SSM ドキュメント ] を選択して、メニューから [自分の SSM ドキュメント] を選択します。また、タイムアウトと再試行のオプションも設定し、スクリプトの 1 つが失敗した場合は Crash-consistent バックアップをデフォルトに設定しています。[ ポリシーをレビュー ] をクリックし、最後の確認をして、次のページの [ ポリシーを作成 ] をクリックします。 自分のポリシーが作成され、すぐに有効になります。少なくとも 1 回実行したら、CloudWatch メトリクスを調べて、開始、完了、失敗の有無を確認できます。 その他の参考資料 先ほどお約束した詳細なブログ投稿の最初の記事は次のとおりです。 MySQL と PostgreSQL のアプリケーション整合性があるスナップショットの作成を自動化する VSS バックアップの作成を自動化する 今年後半に向けてさらに多くの作業を進めており、公開されたら上記のリストを更新します。 また、 ドキュメント を読んで詳細を確認することもできます。 DLM ビデオ この機会に、有用なビデオをいくつかご紹介します。 ポリシーステータスの変化をモニタリングする CloudWatch イベントでポリシーをモニタリングする CloudWatch メトリクスでポリシーアクションをモニタリングする Amazon Data Lifecycle Manager で Amazon EBS スナップショットと AMI を管理する 新しい機能がすでに利用でき、今日からすぐに使用を開始できます。 – Jeff ; 原文は こちら です。

この記事は Backup and restore your Amazon EKS cluster resources using Velero (記事公開日: 2021 年 12 月 1 日) を翻訳したものです。 2023 年 9 月 9 日更新: この記事はもともと 2021 年 12 月 1 日に掲載されました。最新の EKS バージョンと Velero Helm チャートの変更をサポートするため、このブログ記事のウォークスルー手順を更新しました。 世界中の企業がマイクロサービスをカプセル化するためにコンテナを採用しており、その多くはコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するために Kubernetes を選択しています。これらのマイクロサービスの数が増えるにつれて、以下を行うための一元的なバックアップのメカニズムを導入することがますます重要になります。 物理的および論理的なエラーが発生した場合のアプリケーションの保護 Kubernetes クラスター間のマイグレーションの実行 本番環境クラスターの開発環境やテスト環境へのレプリケーション Velero は、Kubernetes クラスターのディザスタリカバリ、データ移行、データ保護を提供する人気のあるオープンソースツールです。Velero は、Kubernetes のクラスターリソースと永続ボリューム (Persistent Volume) を、オンデマンドまたはスケジュールに従って、サポートされた外部のストレージバックエンドにバックアップできます。 Amazon Elastic Kubernetes Service (Amazon EKS) は、高可用かつ安全な Kubernetes クラスターを提供し、パッチ適用、ノードのプロビジョニング、アップデートなどの主要タスクを自動化にするのに役立つマネージドソリューションです。AWS のお客様は、このソリューションを活用して、Kubernetes オブジェクトとアプリケーションを Amazon EKS からバックアップ、および Amazon EKS にリストアできます。これは、お客様は Velero を使用して、セルフホスト型の Kubernetes から Amazon EKS に移行できることも意味します。 このブログ記事では、Velero を使用して Amazon EKS クラスターのリソースをバックアップ、リストア、移行する方法に焦点を当て、組織のユースケースに最適なアプローチを決定するために Velero が提供するバックアップオプションを紹介します。 Velero の概要 このセクションでは、Velero と Amazon EKS の統合方法、このツールがアプリケーションのバックアップとリストアのために提供するカスタマイズ、およびバックアップとリストアのワークフローについて説明します。 Velero と Amazon EKS Amazon EKS のアプリケーションレベルのバックアップは、次の 2 つのコンポーネントが対象となります。 etcd キーバリューストアに保存された Kubernetes オブジェクトとコンフィギュレーション Persistent Volume に保存されたアプリケーションデータ Amazon EKS では、etcd キーバリューストアは AWS によって管理され、Kubernetes API サーバーを介してのみアクセスできます。Velero は Kubernetes API を利用して、キーバリューストアに保存されているデータを取得します。API 呼び出しでは、名前空間 (Namespace)、リソースタイプ、またはラベルによってリソースを簡単にフィルタリングできるため、このアプローチは etcd に直接アクセスするよりも柔軟性があります。例えば、ラベルでフィルタリングしてバックアップの範囲を特定のアプリケーションに制限したり、オブジェクトタイプでフィルタリングして現在の RBAC 戦略を保存したりできます。 また、Velero はクラスターの Persistent Volume のスナップショットを取得し、クラスターのオブジェクトと一緒にリストアできます。詳細は次のセクションで説明します。 バックアップとリストア操作は Kubernetes の カスタムリソース定義 (CRD) オブジェクトとして宣言されます。CRD はこれらの新しい CRD オブジェクトを処理するコントローラーによって管理され、バックアップ、リストア、およびすべての関連操作が実行されます。これらのバックアップとリストアの CRD オブジェクトを作成する際は、以下のカスタマイズを指定できます。 リソースのフィルタリング : Namespace、オブジェクトタイプ、ラベルでフィルタリングして、バックアップやリストアの範囲を制限します。リストア時に、Namespace とオブジェクトタイプを除外してフィルタリングできます。 バックアップタイプの選択 : オンデマンドバックアップを作成するか、定期的にバックアップを自動的に開始するスケジュールを設定します。 保持時間の設定 : バックアップを保持する期間を指定します。 フックの指定 : バックアップまたはリストア操作の前後にコンテナ内でカスタムコマンドを実行するためのプレフックとポストフックを設定します。 バックアップとリストアのワークフロー Velero は 2 つのコンポーネントで構成されます。 Velero サーバー : Amazon EKS クラスター内で実行される Pod Velero CLI : ローカルで実行されるコマンドラインクライアント Amazon EKS クラスターに対してバックアップを発行するたびに、Velero は以下の方法でクラスターリソースのバックアップを実行します。 Velero CLI が Kubernetes API サーバーにアクセスし、バックアップ CRD オブジェクトを作成します。 バックアップコントローラーが以下を実施します。 バックアップ CRD オブジェクトのスコープ、すなわちフィルターが設定されているかどうかをチェックします。 バックアップが必要なリソースについて API サーバーにクエリを実行します。 取得した Kubernetes オブジェクトを .tar ファイルに圧縮し、 Amazon S3 に保存します。 同様に、リストア操作を発行するときは以下のようになります。 Velero CLI は Kubernetes API サーバーにアクセスし、既存のバックアップからリストアするリストア CRD オブジェクトを作成します。 リストアコントローラーが以下を実施します。 リストア CRD オブジェクトを検証します。 Amazon S3 にアクセスしてバックアップファイルを取得します。 リストア操作を開始します。 Velero は、スコープ内の Persistent Volume のバックアップとリストアも実行します。 Amazon Elastic Block Store (Amazon EBS) を使用している場合、Velero はスコープ内の Persistent Volume の Amazon EBS スナップショットを作成します。 その他のボリュームタイプ (hostPath を除く) の場合は、Velero の Restic 統合を使用して、ボリュームの内容のファイルレベルのバックアップを作成します。本記事執筆時点では、Restic はベータ版であるため、本番環境グレードのバックアップには推奨されません。 次のセクションでは、Amazon EKS 上のアプリケーションと関連する EBS ボリュームをバックアップする方法を紹介します。 ウォークスルー 以下のセクションでは、Velero を使用して、あるクラスター内のアプリケーションをバックアップし、そのアプリケーションを別のクラスター内にリストアする方法を説明します。ここでは、人気の高いオープンソースの Ghost パブリッシングプラットフォームを使用して、アプリケーション定義だけでなく、Persistent Volume Claim (PVC) を使用して EBS ボリュームに保存されているステートもバックアップおよびリストアする方法を示します。 前提条件 次のステップに進むためには、以下の前提条件が必要です。 eksctl v0.155.0 以降 : Installing or upgrading eksctl を参照してください。 同じ AWS アカウント内の 2 つの EKS クラスター : Creating an EKS Cluster を参照してください (このブログ記事は、Kubernetes バージョン 1.27 を実行する EKS でテストされました)。 この記事では、この 2 つのクラスターを Primary クラスターと Recovery クラスターと呼びます。 各クラスターは IAM OIDC プロバイダーを設定する必要があります。 Create an IAM OIDC provider for your cluster を参照してください。これは、 IAM Roles for Service Accounts (IRSA)を使用して Velero デプロイメントに必要な AWS アクセス許可を付与するため必要です。 各クラスターには Amazon EBS CSI ドライバー がインストールされている必要があります。 AWS CLI バージョン 2 : Installing, updating, and uninstalling the AWS CLI version 2 を参照してください。 Helm v3 : Installing Helm を参照してください。 kubectl : Installing kubectl を参照してください。 このチュートリアルで使用する 2 つの EKS クラスターは同じアカウントにありますが、これは Velero を使用するためのハード要件ではありません。このブログ記事をガイドラインとして使用し、必要に応じて IAM と S3 バケットのアクセス許可を調整することができます。 以下のセクションのコマンドは Bash を前提として書かれています。 Velero のインストール EKS のベストプラクティスを使用して Velero をインストールするには、いくつかのステップが必要です。まず、バックアップを保存するための S3 バケットを作成します。次に、 IAM Roles for Service Accounts (IRSA) を使用して、バックアップとリストア操作のために必要な AWS アクセス許可を Velero に付与します。最後に、このツールの操作方法を簡素化する Velero CLI をインストールします。 バックアップを保存するための S3 バケットの作成 Velero は、AWS で実行する場合、EKS のバックアップを保存するために S3 を使用します。以下のコマンドを実行して、Velero 用の S3 バケットを作成します。 <company-fqdn>-eks-velero-backups のような一意のバケット名を使用してください。 <BUCKETNAME> と <REGION> は自分の値に置き換えてください。 BUCKET=<BUCKETNAME> REGION=<REGION> aws s3 mb s3://$BUCKET --region $REGION Amazon S3 は、デフォルトで地理的に離れた複数の アベイラビリティーゾーン にデータを保存しますが、コンプライアンス要件により、さらに離れた場所にデータを保存することが求められる場合があります。 クロスリージョンレプリケーション を使用することで、これらの要件を満たすために、離れた AWS リージョン間でデータをレプリケーションすることができます。 IAM ポリシー Velero はスナップショットを実行し、バックアップを S3 バケットに保存するために、EC2 と S3 のリソースに対して多くの API 呼び出しを実行します。以下の IAM ポリシーは、Velero に必要なアクセス許可を付与します。 cat > velero_policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeVolumes", "ec2:DescribeSnapshots", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:DeleteObject", "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::${BUCKET}/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::${BUCKET}" ] } ] } EOF aws iam create-policy \ --policy-name VeleroAccessPolicy \ --policy-document file://velero_policy.json Velero の Service Account の作成 EKS クラスター上で実行されるアプリケーションに AWS ポリシーを提供するためのベストプラクティスは、 IAM Roles for Service Accounts (IRSA) を使用することです。eksctl は、必要な IAM ロールを作成し、信頼関係のスコープを velero-server Service Account に設定する簡単な方法を提供します。 <CLUSTERNAME> は Primary と Recovery の EKS クラスターの名前に置き換えてください。 PRIMARY_CLUSTER=<CLUSTERNAME> RECOVERY_CLUSTER=<CLUSTERNAME> ACCOUNT=$(aws sts get-caller-identity --query Account --output text) eksctl create iamserviceaccount \ --cluster=$PRIMARY_CLUSTER \ --name=velero-server \ --namespace=velero \ --role-name=eks-velero-backup \ --role-only \ --attach-policy-arn=arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy \ --approve eksctl create iamserviceaccount \ --cluster=$RECOVERY_CLUSTER \ --name=velero-server \ --namespace=velero \ --role-name=eks-velero-recovery \ --role-only \ --attach-policy-arn=arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy \ --approve --namespace=velero フラグによって、 velero Namespace で実行されているアプリケーションだけが、前のステップで作成した IAM ポリシーにアクセスできるようになります。 両方の EKS クラスターへの Velero のインストール 以下の手順には、Helm チャートを使用して Velero をインストールするために必要な手順が含まれています。この手順では、Velero バージョン v1.11.1 をインストールするチャートバージョン 5.0.2 を指定していることに注意してください。新しい Velero バージョンをインストールしたい場合は、 互換性マトリックス を使用して Velero AWS プラグインのバージョンを正しい Velero バージョンに合わせるなど、以下の values.yaml ファイルを必ず調整してください。 helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts cat > values.yaml <<EOF configuration: backupStorageLocation: - bucket: $BUCKET provider: aws volumeSnapshotLocation: - config: region: $REGION provider: aws initContainers: - name: velero-plugin-for-aws image: velero/velero-plugin-for-aws:v1.7.1 volumeMounts: - mountPath: /target name: plugins credentials: useSecret: false serviceAccount: server: annotations: eks.amazonaws.com/role-arn: "arn:aws:iam::${ACCOUNT}:role/eks-velero-backup" EOF cat > values_recovery.yaml <<EOF configuration: backupStorageLocation: - bucket: $BUCKET provider: aws volumeSnapshotLocation: - config: region: $REGION provider: aws initContainers: - name: velero-plugin-for-aws image: velero/velero-plugin-for-aws:v1.7.1 volumeMounts: - mountPath: /target name: plugins credentials: useSecret: false serviceAccount: server: annotations: eks.amazonaws.com/role-arn: "arn:aws:iam::${ACCOUNT}:role/eks-velero-recovery" EOF Velero サーバーを 2 回、 Primary クラスターと Recovery クラスターにインストールする必要があります。 kubectl config ( kubectl チートシート ) または kubectx を使用して、両方のクラスターのコンテキストを表示し、コンテキストを簡単に切り替えることができます。 kubectl config の管理を簡単にするために、エイリアスを使用してクラスターを kubeconfig に追加します。 PRIMARY_CONTEXT=primary RECOVERY_CONTEXT=recovery aws eks --region $REGION update-kubeconfig --name $PRIMARY_CLUSTER --alias $PRIMARY_CONTEXT aws eks --region $REGION update-kubeconfig --name $RECOVERY_CLUSTER --alias $RECOVERY_CONTEXT 次のコマンドを使用して、これらの新しいコンテキストがあることを確認できます。 kubectl config get-contexts 「*」が、どのコンテキストにいるかを示しています。 コンテキストを Primary クラスターに変更し、Velero をインストールしましょう。 kubectl config use-context $PRIMARY_CONTEXT helm install velero vmware-tanzu/velero --version 5.0.2 \ --create-namespace \ --namespace velero \ -f values.yaml 次に、コンテキストを Recovery クラスターに変更し、Velero をインストールしましょう。 kubectl config use-context $RECOVERY_CONTEXT helm install velero vmware-tanzu/velero --version 5.0.2 \ --create-namespace \ --namespace velero \ -f values_recovery.yaml 各コンテキストで以下のコマンドを実行することで、Velero サーバーが正常にインストールされたことを確認できます。 kubectl get pods -n velero Velero CLI のインストール Velero はコマンドを CRD としてを送信することで動作します。クラスターのバックアップを作成するには、クラスターにバックアップ CRD を送信します。これを手作業で作成するのは難しい場合があるため、Velero チームはバックアップとリストアを簡単に実行できる CLI を作成しました。ここでは、Velero CLI を使用して Primary クラスターのバックアップを作成し、 Recovery クラスターにリストアします。 インストール手順はオペレーティングシステムによって異なります。 こちら の手順に従って Velero をインストールしてください。 サンプルアプリケーションのバックアップとリストア Velero をインストールした状態で、 Primary クラスターにアプリケーションをインストールしてバックアップし、 Recovery クラスターにリストアを行います。お客様は、以下の手順に従って、自分の Amazon EKS クラスター内の自分のアプリケーションをバックアップおよびリストアすることもできます。 Ghost アプリケーションのインストール (および記事の作成) Ghost をサンプルアプリケーションとして Primary クラスターにバックアップし、 Recovery クラスターにリストアします。一般的にデプロイされ、十分にテストされている Bitnami Helm チャート を使用します。このチャートは、ブログアプリケーションのための永続的なデータストアとして機能する Bitnami MySQL チャート に依存しています。MySQL のデータは EBS ボリュームに保存され、バックアップ実行の一環として Velero によってスナップショットが作成されます。 それでは、 Primary クラスターにコンテキストに切り替え、Ghost をインストールしましょう (Ghost をインストールするときに表示される通知 ERROR: You did not provide an external host は無視してください。これは次のコマンドで解決されます)。 kubectl config use-context $PRIMARY_CONTEXT helm install ghost oci://registry-1.docker.io/bitnamicharts/ghost \ --create-namespace \ --namespace ghost export APP_HOST=$(kubectl get svc --namespace ghost ghost --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}") export GHOST_PASSWORD=$(kubectl get secret --namespace "ghost" ghost -o jsonpath="{.data.ghost-password}" | base64 -d) export MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-root-password}" | base64 -d) export MYSQL_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-password}" | base64 -d) helm upgrade ghost oci://registry-1.docker.io/bitnamicharts/ghost \ --namespace ghost \ --set service.type=LoadBalancer \ --set ghostHost=$APP_HOST \ --set ghostPassword=$GHOST_PASSWORD \ --set mysql.auth.rootPassword=$MYSQL_ROOT_PASSWORD \ --set mysql.auth.password=$MYSQL_PASSWORD 次のコマンドを実行することで、インストールが成功したことを確認できます。 kubectl get pods -n ghost Persistent Volume のバックアップとリストアをデモするブログ記事の作成 Helm チャートのインストールが完了すると、コンソールにチャートの README が表示されます。 これには次のものが含まれます。 ブログ URL 管理 URL デフォルトの管理者ユーザー名 kubectl を使用してパスワードを取得する手順 オプションで、(上に表示されている管理 URL を使用して) Ghost 管理コンソールにサインインし、バックアップとリストアのプロセスに含めるサンプルのブログ記事を作成することができます。これにより、バックアップにはアプリケーションのデプロイメント構成だけではなく、すべての記事を含むブログデータベースの状態も含まれることが確認できます。 記事を作成するには、まず左側のナビゲーションペインで Posts を選択します。 次に、ページの右上にある New post を選択します。 記事のタイトルを追加し、内容を書くことができます。サンプルのブログ記事を保存する準備ができたら、ページの右上にある Publish ドロップダウンメニュー項目を選択し、ドロップダウンメニューから Publish ボタンを選択します。 バックアップの作成 Primary クラスターのバックアップを作成しましょう。以下のコマンドを実行する前に、kubectl コンテキストが Primary クラスターに設定されていることを確認してください。 velero backup create ghost-backup -o フラグを使用することで、Velero のバックアップ CRD がどのように見えるかを確認できます。これは、実際にバックアップ作成を Velero サーバーに送信せずに、バックアップ CRD の YAML を出力します。 velero backup create test -o yaml バックアップ CRD では、 includedNamespaces 配列にワイルドカードが含まれているため、すべての Namespace をバックアップしていることがわかります。クラスター全体をバックアップしている場合でも、セレクターを使用してクラスターの個々のコンポーネントを選択できます。これにより、例えば単一のアプリケーションを含む単一の Namespace をバックアップできます。 バックアップが成功したことの検証 バックアップのステータスを確認し、バックアップが正常に完了したことを確認しましょう。 velero backup describe ghost-backup コマンドの出力で、 Phase: フィールドを探します。現在の Phase が InProgress の場合、しばらく待ってから Phase: Completed が表示されるまで再試行してください。開始時刻や完了時刻、バックアップされたアイテムの数などの情報を含む、バックアップの追加の詳細を確認できます。 以前に作成した Amazon S3バケット内に、Velero が作成したバックアップファイルを確認できます。 aws s3 ls $BUCKET/backups/ghost-backup/ アプリケーションの Recovery クラスターへのリストア kubectl コンテキストを Recovery クラスターに切り替えます。 kubectl config use-context $RECOVERY_CONTEXT 次のコマンドを使用して、Ghost アプリケーションのみを Recovery クラスターにリストアします。 velero restore create ghost-restore \ --from-backup ghost-backup \ --include-namespaces ghost リストアが成功したことの検証 リストアのステータスを確認し、リストアが正常に完了したことを確認しましょう。 velero restore describe ghost-restore 出力の Phase: Completed を探してください。 Phase: InProgress と表示された場合は、しばらく待ってからコマンドを再実行してください。次に、 Recovery クラスター内の Ghost ブログの LoadBalancer Service の URL を取得します。 kubectl -n ghost get svc ghost EXTERNAL-IP の URL にアクセスして、ブログがリストアされたことを確認します。Ghost ブログと、前のステップで作成したサンプルのブログ記事が表示されるはずです。 おめでとうございます！ Primary クラスターのバックアップと、 Recovery クラスターへのアプリケーションのリストアに成功しました。 本番環境のバックアップ/リストア/DR 操作では、サービスが期待通りに動作していることを確認した後、本番の DNSレコードが Recovery クラスターを指すように移動する必要がある点に注意してください。 クリーンアップ 今後の課金が発生しないようにするために、リソースを削除してください。 eksctl を使ってクラスターを作成した場合は、 eksctl delete cluster <clustername> コマンドを使用してクラスターを削除できます。 バックアップを保存するために使用した S3 バケットと、Velero が使用している IAM ロールも削除する必要があります。 aws s3 rb s3://$BUCKET --force aws iam delete-policy --policy-arn arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy まとめ ディザスタリカバリとマイグレーション戦略にはいくつかの種類があります。このブログ記事では、Velero が障害や災害イベントからの迅速なリカバリと、Amazon EKS のアプリケーションとクラスターリソースのシームレスな移行をどのように保証するかを紹介しました。このツールが提供するオプションをハイライトし、ステートフルアプリケーションをバックアップして新しいクラスターにリストアするプロセスを紹介しました。同様に、お客様は自分のアプリケーションと Kubernetes リソースを他の Amazon EKS クラスターにマイグレーション、レプリケーション、または以前のアプリケーション状態をリストアすることもできます。 このアプローチにより、単に CI/CD パイプラインをリダイレクトして新しい EKS クラスターにデプロイするのとは対照的に、ディザスタリカバリやマイグレーションイベントのためのオペレーションを一元化できます。これは、Kubernetes においてアプリケーションのデプロイやアップデートに使用される CI/CD パイプラインは、このような状況では必要のないアクションを実行する可能性があるためです。さらに、データの永続化に対処するためのアプローチを別途考える必要もあります。代わりに、このようなイベントのための特定の CI/CD パイプラインを作成することができます。 セルフマネージド型の Kubernetes クラスターの場合、お客様は Amazon EKS への移行にこのオープンソースツールを使用することもできます。このユースケースを深く掘り下げるには、 このブログ記事 で説明されているベストプラクティスに従うことをお勧めします。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

2023年も終わりを迎え、クリスマスまであと 50 日、AWS re:Invent まであと 21 日! ラスベガスにいるなら、私に挨拶しに来てください。私はほとんどの時間、Serverlesspresso のブースにいます。 10月30日週のリリース 10月30日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon EC2 – Amazon EC2 は ML 向けキャパシティブロックを発表しました。これは、短時間の ML ワークロード用に GPU コンピュートキャパシティを予約できるようになったことを意味します。このリリースについての詳細は、 特集ページ と 発表ブログ記事 をご覧ください。 Finch – Finch の一般公開を開始しました。Finch は、macOS (Intel または Apple Silicon を使用) でローカルコンテナ開発を行うためのオープンソースツールです。macOS 上で Linux コンテナを構築、実行、公開するためのコマンドライン開発者ツールを提供します。Finch についての詳細は、 Phil Estes が書いたこのブログ記事 、または Finch のウェブサイトをご覧ください。 AWS X-Ray – AWS X-Ray が分散トレース用の W3C 形式のトレース ID をサポートしました 。AWS X-Ray は、OpenTelemetry または W3C Trace Context 仕様に準拠するその他のフレームワークを通して生成されたトレース ID をサポートします。 Amazon Translate – Amazon Translate は、翻訳出力の長さを短縮するための簡潔性のカスタマイズを導入しています 。これは、キャプションサイズの制限を満たすために短い翻訳が必要なリアルタイム翻訳で有効にできる新機能です。この翻訳は文字通りのものではありませんが、根本的なメッセージは保たれます。 AWS IAM – IAM は 最後にアクセスしたアクション を 60 のサービスに増やしました 。この機能は、ロールのパーミッションを微調整し、未使用のパーミッションを特定し、ロールが必要とする最小限のパーミッションを付与する場合に非常に便利です。 AWS IAM Access Analyzer – IAM Access Analyzer ポリシージェネレータは、AWS CloudTrail のアクセスアクティビティに基づいてきめ細かいポリシーを作成するために、 200 以上の AWS サービスを識別するためのサポートを拡張しました。 AWS のお知らせの完全なリストについては、 「AWS の最新情報」ページをご覧ください。 その他の AWS ニュース 見逃したかもしれない他のニュースやブログ記事: AWS Compute Blog – Daniel Wirjo と Justin Plock が、 様々な AWS サーバーレスサービスを使用して AWS 上で Webhook を送受信する方法について非常に興味深い記事を書いています。アプリケーションでウェブフックを使っているなら、これは良い読み物です。これは、これらのソリューションを構築する方法を示すだけでなく、構築する際にどのような配慮が必要かも示しています。 AWS Storage Blog – Bimal Gajjar と Andrew Peace が、 Amazon S3 Event Notifications でイベントの順序と重複イベントを処理する方法について、とても役に立つブログ記事を書いてくれました。これは多くの顧客に共通する課題です。 Amazon Science Blog – David Fan は、 映像表現のためのより良い基礎モデルを構築する方法についての記事を書きました。この記事は、Prime Video がこのトピックに関する会議で発表した論文に基づいています。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報  – 私の同僚である Ricardo  が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Days  – お住まいの地域で AWS ユーザーグループのリーダーが主催するコミュニティ主導のカンファレンスにぜひご参加ください: エクアドル (11 月 7 日)、 メキシコ (11 月 11 日)、 モンテビデオ (11 月 14 日)、 中央アジア (カザフスタン、ウズベキスタン、キルギス、モンゴル: 11 月 17～18 日)、 グアテマラ (11 月 18 日)。 AWS re:Invent (11 月 27 日～12 月 1 日) – AWS の最新情報を聞き、エキスパートから学び、グローバルクラウドコミュニティとつながるために ぜひご参加ください 。 セッションカタログ と 参加者ガイド を確認し、 生成系人工知能 (AI) のハイライト をご覧ください。 11月6日週はここまでです。11月13日週の Weekly Roundup もお楽しみに! –  Marcia この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2024 年半以降、新しくリリースされた Amazon EC2 インスタンスタイプは EC2 インスタンスメタデータサービス (IMDSv2) のバージョン 2 のみを使用します。また、IMDSv2 を AWS マネジメントコンソールのクイックスタートやその他の起動経路のデフォルト選択肢にするために一連のステップが実施されています。 背景 このサービスには、EC2 インスタンス内から固定 IP アドレス (IPv4 の 169.254.169.254 または Nitro インスタンス上の IPv6 の fd00:ec2::254 ) でアクセスできます。これにより、ユーザー (またはインスタンス上で実行しているコード) は、インスタンスの起動に使用された AMI の ID、ブロックデバイスマッピング、インスタンスにアタッチされたロールの一時的な IAM 認証情報、ネットワークインターフェイス情報、ユーザーデータを始めとする豊富な静的および動的データにアクセスできます。詳細については、「 インスタンスメタデータのカテゴリ 」を参照してください。 このブログ で詳細に説明されているように、v1 サービスはリクエスト/レスポンスのアクセス方式を使用し、v2 サービスはセッション指向の方法を使用します。どちらのサービスも完全に安全ですが、v2 では IMDS へのアクセスを試みる際に悪用される可能性のある 4 種類の脆弱性に対する追加の保護レイヤーが提供されます。 多くのアプリケーションやインスタンスが既に IMDSv2 を使用して、多くののメリットを活用していますが、完全なメリットは、AWS アカウントレベルで IMDSv1 が無効化されている場合にのみ利用できます。 移行計画 IMDSv2 を新しい AWS インフラストラクチャのデフォルトの選択肢にするために実施された重要なステップと今後予定されているステップを以下に示します (2023 年と 2024 年の日付に若干のずれがあります)。 2019 年 11 月 – IMDSv2 がローンチ され、これを使用して徹底的な防御を追加する方法が紹介されました。 2020 年 2 月 – AWS Marketplace の出品者と AWS パートナーから新たに公開されたすべての製品が IMDSv2 をサポートしていることの検証が開始されました。 2023 年 3 月 – すべてのローンチにおいてデフォルトで IMDSv2 を使用する Amazon Linux 2023 がローンチされました。 2023 年 9 月 – IMDSv2 のメリットを最大限に活用し、AWS インフラストラクチャ全体で IMDSv1 を無効にする方法 を紹介するブログ記事が公開されました。 2023 年 11 月 – 本日より、すべてのコンソールのクイックスタートローンチで IMDSv2 のみが使用されるようになります (Amazon とパートナークイックスタート AMI はすべてこれをサポートします)。次の図は、これをインスタンスの起動時に EC2 コンソールの 高度な詳細 で指定する方法を示しています。 2024 年 2 月 – アカウントレベルで IMDSv1 の使用をデフォルトとして制御できる新しい API 機能が導入される予定です。現在、IMDSv1 の使用は、IAM ポリシーでの制御 (既存のアクセス許可の取り消しと制限) に加えて、アカウント、組織単位 (OU)、または組織全体にグローバルに適用される SCP として制御することが可能です。IAM ポリシーの例については、「 インスタンスメタデータの使用 」を参照してください。 2024 年半ば – 新しくリリースされた Amazon EC2 インスタンスタイプは、デフォルトで IMDSv2 のみを使用します。移行をサポートするために、これまで同様に、インスタンス上での起動時または起動後に再起動や停止/開始を必要とせずに IMDSv1 を有効化できます。 対処 完全なメリットを取得 する方法を解説したブログ記事を参照して IMDSv1 から IMDSv2 への移行を開始できます。 IMDSv2 への移行に役立つツール 、および同じページで紹介されている推奨パスについても理解しておいてください。このページでは、ツールの推奨に加えて、IMDSv1 の使用を無効にする IAM ポリシーの設定方法、および MetadataNoToken CloudWatchメトリクスを使用して残りの使用量を検出する方法も示されています。 もう 1 つの便利なリソースが AWS re:Post にあります (「 Systems Manager オートメーションを使用して、Amazon EC2 インスタンスからインスタンスメタデータにアクセスするために IMDSv2 のみを使用するように強制するにはどうすればよいですか? 」)。 この移行がお客様とお客様の顧客にとって可能な限りスムーズなものとなることを望んでいます。追加のサポートが必要な場合は、 AWS サポート にお問い合わせください。 – Jeff ; 原文は こちら です。

機械学習 (ML) における最近の進歩は、あらゆる規模と業界にまたがる組織が新しい製品を考案し、ビジネスを変革する機会を生み出しました。しかし、これらの ML モデルのトレーニング、微調整、実験、および推論を行うための GPU 容量に対する需要の拡大に業界全体の供給が追いつかなくなっているため、GPU は希少なリソースになっています。取り組んでいる研究開発フェーズに応じて容量のニーズが変動するお客様にとって、GPU 容量へのアクセスは障害になります。 10月31日、AWS は Amazon Elastic Compute Cloud (Amazon EC2) の ML 向けキャパシティブロック を発表しました。これは、ML および 生成系 AI モデルをトレーニングしてデプロイするための GPU インスタンスに簡単にアクセスできるようにすることで、ML の民主化をさらに進める Amazon EC2 の新しい使用モデルです。EC2 キャパシティブロックを使用することで、高パフォーマンス ML ワークロード向けに設計された EC2 UltraClusters に配置されている何百もの GPU を予約することができます。これには、ペタバイト規模のノンブロッキングネットワーク内にある Elastic Fabric Adapter (EFA) ネットワーキングが使用され、Amazon EC2 で利用できる最高のネットワークパフォーマンスを提供します。 これは GPU インスタンスをスケジュールするための新しい革新的な方法で、後日に必要となる数のインスタンスを、必要な時間分だけ予約することができます。現在、EC2 キャパシティブロックは AWS 米国東部 (オハイオ) リージョン内にある NVIDIA H100 Tensor Core GPU 搭載の Amazon EC2 P5 インスタンス でご利用いただけます。EC2 キャパシティブロックでは、数回クリックするだけで GPU インスタンスを予約し、自信を持って ML 開発を計画できます。EC2 キャパシティブロックは、ML トレーニングに対して EC2 で最高のパフォーマンスを提供する EC2 P5 インスタンスへの予定どおりのアクセスを、誰もが簡単に実現できるようにします。 EC2 キャパシティブロックの予約は、ホテルの部屋を予約するしくみに似ています。ホテルの予約では、部屋を予約したい日付と期間、および希望するベッドのサイズ (クイーンサイズのベッドやキングサイズのベッドなど) を指定します。これと同様に、EC2 キャパシティブロック予約でも、 GPU インスタンスが必要になる日付と期間、および予約のサイズ (インスタンスの数) を選択します。予約の開始日になると、予約した EC2 キャパシティブロックにアクセスして P5 インスタンスを起動できるようになります。EC2 キャパシティブロックの期間終了時に実行中のインスタンスは、すべて終了されます。 EC2 キャパシティブロックは、ML モデルをトレーニングもしくは微調整する、実験を行う、または ML アプリケーションに対する需要の将来的な急増に備えるために、容量を保証しておく必要がある場合に使用できます。一方で、ビジネスクリティカルなアプリケーション、規制要件、またはディザスタリカバリなど、コンピューティング能力の保証が必要となるその他すべてのワークロードタイプには、引き続き オンデマンドキャパシティ予約 を使用することができます。 ML 向けの Amazon EC2 キャパシティブロックの使用を開始する キャパシティブロックを予約するには、米国東部 (オハイオ) リージョンの Amazon EC2 コンソール で、[ キャパシティーの予約 ] を選択します。2 つのキャパシティ予約オプションが表示されます。[ キャパシティブロックを購入 ] を選択してから、[ ご利用開始にあたって ] を選択して、EC2 キャパシティブロックの検索を開始します。 合計キャパシティを選択し、EC2 キャパシティブロックが必要になる期間を指定します。EC2 キャパシティブロックは、1、2、4、8、16、32、または 64 個の p5.48xlarge インスタンスのサイズで予約できます。EC2 キャパシティブロックを予約できる合計日数は 1～14 日で、1 日単位になっています。EC2 キャパシティブロックは最大 8 週間前に購入できます。 EC2 キャパシティブロックの料金は動的で、EC2 キャパシティブロックの購入時における利用可能な総供給量と需要に応じて変動します。仕様内のサイズ、期間、または日付範囲を調整することで、他の EC2 キャパシティブロックオプションを検索できます。[ キャパシティブロックを検索 ] を選択すると、AWS が、ユーザー指定の日付範囲内で仕様を満たす、利用可能な最低料金のオプションを返します。この時点で、EC2 キャパシティブロックの料金が表示されます。 EC2 キャパシティブロックの詳細、タグ、および合計料金情報を確認したら、[ 購入 ] を選択します。EC2 キャパシティブロックの合計料金は前払いで請求され、購入後に料金が変更されることはありません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。 すべての EC2 キャパシティブロック予約は、協定世界時 (UTC) の午前 11 時 30 分に開始されます。購入後に EC2 キャパシティブロックを変更またはキャンセルすることはできません。 EC2 キャパシティブロックは、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を使用して購入することもできます。 describe-capacity-block-offerings API を使用してクラスター要件を指定し、購入可能な EC2 キャパシティブロックを見つけます。 $ aws ec2 describe-capacity-block-offerings \           --instance-type p5.48xlarge \           --instance-count 4 \           --start-date-range 2023-10-30T00:00:00Z \           --end-date-range 2023-11-01T00:00:00Z \           –-capacity-duration 48 上記コマンドからの CapacityBlockOfferingId とキャパシティ情報を使用して利用可能な EC2 キャパシティブロックを見つけたら、 purchase-capacity-block-reservation API を使用してキャパシティブロックを購入できます。 $ aws ec2 purchase-capacity-block-reservation \           --capacity-block-offering-id cbr-0123456789abcdefg \           –-instance-platform Linux/UNIX 新しい EC2 キャパシティブロック API の詳細については、 Amazon EC2 API ドキュメント を参照してください。 これで、EC2 キャパシティブロックが正常にスケジュールされました。スケジュールされた開始日になると、EC2 キャパシティブロックがアクティブになります。開始日にアクティブな EC2 キャパシティブロックを使用するには、その EC2 キャパシティブロックのキャパシティ予約 ID を選択します。[ キャパシティ予約の詳細 ] セクションにはリザーブドインスタンスキャパシティの内訳が表示されており、キャパシティが現在どのように使用されているかがわかります。 アクティブな EC2 キャパシティブロックにインスタンスを起動するには、[ インスタンスを起動 ] を選択し、EC2 インスタンスを起動して ML ワークロードを実行するための通常のプロセスに従います。 [ 高度な詳細 ] で、[ キャパシティブロック ] を購入オプションとして選択し、ターゲットにしようとしている EC2 キャパシティブロックのキャパシティ予約 ID を選択します。 EC2 キャパシティブロックの終了時間が近づくと、Amazon EC2 が Amazon EventBridge を通じてイベントを送信して予約が間もなく終了することを通知するので、ワークロードのチェックポイントを設定することができます。EC2 キャパシティブロックで実行中のインスタンスは、予約が終了する 30 分前にシャットダウン中状態になります。EC2 キャパシティブロックに対して請求された金額に、この 30 分間は含まれていません。EC2 キャパシティブロックの有効期間終了時に実行中のインスタンスは、すべて終了されます。 今すぐご利用いただけます Amazon EC2 キャパシティブロック は、AWS 米国東部 (オハイオ) リージョンの p5.48xlarge インスタンスで今すぐご利用いただけます。EC2 キャパシティブロックの料金は予約前に確認でき、EC2 キャパシティブロックの合計料金は購入時に前払いで請求されます。詳細については、 EC2 キャパシティブロックの料金 ページを参照してください。 EC2 キャパシティブロックの詳細については、 EC2 キャパシティブロックドキュメント を参照してください。フィードバックは、 AWS re:Post for EC2 、または通常の AWS サポート連絡先をとおして送信してください。 – Channy 原文は こちら です。

AWS re:Invent まであと 1 か月を切りましたが、その間も興味深いニュースが続々と発表されています。10月30日週は、私が皆様に最新情報をお知らせします! 先週のリリース 10月23日週、私の目に留まったリリースをいくつかご紹介します。 AWS re:Post – re:Post では、AWS を利用してさらなる成功を実現するのに役立つエキスパートのコミュニティにアクセスできます。 Selections では、コミュニティメンバーは集約ビューで知識を整理し、 学習パスや厳選されたコンテンツセットを作成できます。 Amazon SNS – FIFO (先入れ先出し) トピックが、別のアーカイブリソースのプロビジョニングを必要とせずに、 メッセージを保存および再生するオプションをサポートするようになりました 。これは、イベント駆動型アプリケーションの耐久性を向上させ、ダウンストリームの障害シナリオから回復するのに役立ちます。詳細については、AWS コンピューティングブログの記事「 Archiving and replaying messages with Amazon SNS FIFO 」をご覧ください。また、 カスタムデータ識別子 を使用して、一般的な機密データ (名前、住所、クレジットカード番号など) だけでなく、会社の従業員 ID などのドメイン固有の機密データも保護できるようになりました。この機能の詳細については、AWS セキュリティブログの記事「 Mask and redact sensitive data published to Amazon SNS using managed and custom data identifiers 」をご覧ください。 Amazon SQS – FIFO 高スループットモードのためのスループットクォータの引き上げ により、API アクションごとに 1 秒あたり最大 18,000 のトランザクションを処理できます。スループットクォータは AWS リージョンによって異なることにご留意ください。 Amazon OpenSearch Service – OpenSearch Serverless は、新しいインデックスライフサイクルポリシーにより、 時間ベースの自動データ削除 をサポートするようになりました。 正確で低レイテンシーのベクトル検索クエリを提供するための最適な戦略を決定 するために、OpenSearch は、 近似最近傍探索 (ANN) を使用した事前フィルタリングや、正確な k-最近傍 (k-NN) を使用したフィルタリングなど、 最適なフィルタリング戦略をインテリジェントに評価 できるようになりました。また、OpenSearch Service は、 インターネットプロトコルバージョン 6 (IPv6) をサポートするようになりました 。 Amazon EC2 – マルチ VPC ENI アタッチメント を使用すると、1 つの仮想プライベートクラウド (VPC) 内でプライマリ Elastic Network Interface (ENI) を使用してインスタンスを起動し、別の VPC からセカンダリ ENI をアタッチできます。これは、ネットワークレベルの分離を維持するのに役立ちますが、特定のワークロード (一元管理されたアプライアンスやデータベースなど) が相互に通信するのを引き続き許可します。 AWS CodePipeline – パラメータ化されたパイプライン を使用すると、入力パラメータをパイプライン実行に動的に渡すことができます。ソースリポジトリ内の コミットに特定の git タグが適用された際にパイプラインの実行を開始 できるようになりました。 Amazon MemoryDB – Graviton3 ベースの R7g ノードをサポート するようになりました。これは、R6g と比較して最大 28% 多いスループットを実現します。また、これらのノードは、より高いネットワーク帯域幅も提供します。 その他の AWS のニュース ここでは、私が注目している AWS およびクラウドに関する他のブログ記事をいくつかご紹介します。 ネットワーキングとコンテンツ配信のブログ – AWS ネットワークインフラストラクチャを構築する際に下す、技術管理とハードウェアに関する意思決定の一例:「 A Continuous Improvement Model for Interconnects within AWS Data Centers 」 DevOps ブログ – 企業のお客様が CodeWhisperer を利用しているデベロッパーの数、利用頻度、提案を受け入れる頻度を理解するのをサポートします:「 Introducing Amazon CodeWhisperer Dashboard and CloudWatch Metrics 」 フロントエンドウェブおよびモバイルブログ – GraphQL API へのアクセスをプライベートネットワーク内のコンシューマーに制限する方法:「 Architecture Patterns for AWS AppSync Private APIs 」 アーキテクチャブログ – この非常に興味深いシリーズの新しい記事:「 Let’s Architect! Designing systems for stream data processing 」 Community.AWS から:「 Load Testing WordPress Amazon Lightsail Instances 」および「 Future-proof Your .NET Apps With Foundation Model Choice and Amazon Bedrock 」。 私の同僚の Ricardo による AWS の最新のオープンソースに関するニュースレター もお見逃しなく。 今後の AWS イベント カレンダーを確認して、次の AWS イベントにぜひサインアップしてください。 AWS Community Days  – お住まいの地域で AWS ユーザーグループのリーダーが主催するコミュニティ主導のカンファレンスにぜひご参加ください: ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、 ブラジル (11 月 4 日)、 中央アジア (カザフスタン、ウズベキスタン、キルギス、モンゴル: 11 月 17～18 日)、 グアテマラ (11 月 18 日)。 AWS re:Invent (11 月 27 日～12 月 1 日) – AWS の最新情報を聞き、エキスパートから学び、グローバルクラウドコミュニティとつながるために ぜひご参加ください 。 セッションカタログ と 参加者ガイド を確認し、 生成系 AI のハイライト をご覧ください。 こちらでは、今後のすべての AWS 主導の対面および仮想イベント と デベロッパー中心のイベント を確認できます。 10月30日週はここまでです。次回もお楽しみに! – Danilo この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

訳者注記： 原文記事 は 2019 年の記事となりますが、定期的にメンテナンスされており、且つ DNS 管理において有用であるため翻訳対象として選定しています。 前回の投稿 では、マルチアカウント環境にCentral DNS を実装するソリューションを紹介しました。これにより、クロスアカウントや AWS からオンプレミスへのドメイン解決を実装するときに必要なサーバーとフォワーダーの数が減り、DNS 管理が簡素化されます。 Amazon Route 53 Resolver サービスのリリースにより、ハイブリッド DNS 解決をさらに簡素化するネイティブの条件付きフォワーダーにアクセスできるようになりました。 この記事では、Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を一元化する最新のソリューションを紹介します。このソリューションにより、AWS でドメインコントローラーを実行しなくても、複数のアカウントにわたって、また AWS とオンプレミスで実行されているワークロード間でドメインを解決できます。 ソリューションの概要 このソリューションでは、ドメイン解決の 3 つの主要なユースケースを解決する方法を示します。 VPC で実行されているワークロードからオンプレミスドメインの名前解決 オンプレミスで実行されているワークロードから AWS 環境内のプライベートドメインの名前解決 異なる AWS アカウントで実行されているワークロード間のプライベートドメインの名前解決 次の図は、大まかなアーキテクチャを示しています。 図 1: アーキテクチャ図 アーキテクチャ図中の 1 ~ 6 について説明します。 Central DNS VPC 用のAmazon が提供するデフォルト DNS サーバーです。ここでは、これを DNS-VPC と呼びます。これは VPC CIDR 範囲内の 2 番目の IP アドレスです (図に示されているように、 172.27.0.2 を持ちます)。このデフォルトの DNS サーバーは、参加している AWS アカウントで実行されるすべてのワークロードのプライマリドメインリゾルバーになります。 Route 53 Resolver Endpoint を示しています。インバウンドエンドポイントは、オンプレミスの DNS サーバーと、参加している AWS アカウントで実行されているワークロードから転送されたクエリを受信します。アウトバウンドエンドポイントは、ドメインクエリを AWS からオンプレミス DNS に転送するために使用されます。 条件付き転送ルールを示しています。このアーキテクチャでは、2 つのルールが必要です。1 つは onprem.private ゾーンのドメインクエリをアウトバウンドエンドポイント経由でオンプレミス DNS サーバーに転送するルール、もう 1 つは awscloud.private のドメインクエリを DNS-VPC のリゾルバーインバウンドエンドポイントに転送するルールです。 これら 2 つの転送ルールが AWS Resource Access Manager を介して他のすべての AWS アカウントと共有され、これらのアカウントのすべての VPC に関連付けられていることを示しています。 awscloud.private という固有のサブドメインを使用して各アカウントに作成されたプライベートホストゾーンを示しています。 awscloud.private ゾーンへのクエリを Resolver インバウンドエンドポイントの IP アドレスに転送するように設定された条件付きフォワーダーを備えたオンプレミスの DNS サーバーを示しています。 注:このソリューションでは、送信元/宛先の VPC と DNS-VPC 間の VPC ピアリングや接続は必要ありません。 仕組み 次に、このアーキテクチャのドメイン解決フローが、3 つのユースケースに従ってどのように機能するかを示します。 ユースケース ① 図 2: AWS で実行されているワークロードからオンプレミスドメインを解決するユースケース 最初に、AWS で実行されているワークロードからオンプレミスドメインを解決する方法を見ていきます。プライベートドメイン host1.acc1.awscloud.private のサーバーが host1.onprem.private というアドレスを解決しようとすると、次のようになります。 DNS クエリは、host1.acc1.awscloud.private をホストしている VPC のデフォルト DNS サーバーにルーティングされます。 VPC は Central DNS アカウントから共有される転送ルールに関連付けられているため、これらのルールは VPC 内の Amazon が提供するデフォルトの DNS によって評価されます。 この例では、ルールの 1 つが onprem.private のクエリをオンプレミス DNS サーバーに転送するように指示しています。このルールに従って、クエリはオンプレミスの DNS サーバーに転送されます。 転送ルールは Resolver アウトバウンドエンドポイントに関連付けられているため、クエリはこのエンドポイントを介してオンプレミスの DNS サーバーに転送されます。 このフローでは、参加しているアカウントの1つで開始されたDNSクエリが Central DNS サーバーに転送され、次にオンプレミス DNS に転送されます。 ユースケース ② 次に、オンプレミスのワークロードで AWS 環境のプライベートドメインを解決する方法は次のとおりです。 図 3: オンプレミスのワークロードで AWS 環境のプライベートドメインを解決する方法のユースケース この場合、host1.acc1.awscloud.private のクエリはオンプレミスホストから開始されます。次に何が起こるかは次のとおりです。 ドメインクエリはオンプレミスの DNS サーバーに転送されます。 その後、クエリはオンプレミスDNSサーバー上の条件付き転送ルールを介して Resolver インバウンドエンドポイントに転送されます。 クエリは、DNS-VPC のデフォルト DNS サーバーに到達します。 DNS-VPC はプライベートホストゾーン acc1.awscloud.private に関連付けられているため、デフォルトの DNS サーバーがこのドメインを解決できます。 この場合、DNS クエリはオンプレミスで開始され、インバウンドエンドポイントを通じて AWS 側の Central DNS に転送されています。 ユースケース③ 最後に、複数の AWS アカウントにまたがるドメインの解決が必要になる場合があります。これを実現する方法は次のとおりです。 図 4: 複数の AWS アカウントにまたがるドメインを解決する方法のユースケース host1.acc1.awscloud.private のホスト 1 が host2.acc2.awscloud.private というドメインを解決しようとしたとすると、次のことが起こります。 ドメインクエリは、VPC ホスティングソースマシン (host1) のデフォルト DNS サーバーに送信されます。 VPC は共有転送ルールに関連付けられているため、これらのルールは評価されます。 awscloud.private ゾーンのクエリは、DNS-VPC のインバウンドエンドポイントに (アウトバウンドエンドポイント経由で) 転送する必要があるというルールがあります。 次に、アウトバウンドエンドポイントは DNS クエリをターゲット IP に転送します。この例では、ターゲット IP は受信エンドポイントの IP アドレスです。 DNS-VPC は acc2.awscloud.private ホストゾーンに関連付けられているため、デフォルトの DNS は自動定義ルールを使用してこのドメインを解決します。 このユースケースでは、DNS クエリが 1 つの参加アカウントで開始され、別の AWS アカウントのドメイン解決のために Central DNS に転送される、AWS 間ケースについて説明します。次に、このソリューションをお客様の環境で構築するために何が必要かを見ていきます。 ソリューションの導入方法 このソリューションを 4 つのステップで構成する方法を説明します。 一元化された DNS アカウントを設定します。 各参加アカウントを設定します。 プライベートホストゾーンと Route 53 の関連付けを作成します。 オンプレミスの DNS フォワーダーを設定します。 ステップ 1: Central DNS アカウントを設定する このステップでは、一元管理された DNS アカウントにリソースを設定します。主に、DNS-VPC、リゾルバーエンドポイント、転送ルールが含まれます。 ウェブコンソール または AWS クイックスタート を使用して、ビジネスシナリオに応じて DNS-VPC として動作する VPC を作成します。 Amazon VPC ユーザーガイド で一般的なシナリオを確認できます。非常に一般的なシナリオの 1 つは、 パブリックサブネットとプライベートサブネットを持つ VPC です。 リゾルバーエンドポイントを作成 します。DNS クエリをオンプレミス DNS に転送するアウトバウンドエンドポイントと、オンプレミスのワークロードや他の AWS アカウントから転送された DNS クエリを受信するインバウンドエンドポイントを作成する必要があります。 2 つの 転送ルール を作成します。最初のルールは、ゾーン onprem.private の DNS クエリをオンプレミスの DNS サーバーの IP アドレスに転送することです。2 番目のルールは、ゾーン awscloud.private の DNS クエリをリゾルバーのインバウンドエンドポイントの IP アドレスに転送することです。 ルールを作成したら、ゾーン onprem.private のルールをステップ #1 で作成した DNS-VPC に関連付け ます(他の転送ルールを DNS-VPC に関連付ける必要はありません)。これにより、Route 53 リゾルバーはドメインクエリの転送をそれに応じて開始できます。 最後に、 2 つの転送ルールをすべての参加アカウントと共有する 必要があります。そのためには、AWS Resource Access Manager を使用し、ルールを AWS 組織全体または特定のアカウントと共有できます。 注:ドメインクエリをオンプレミスの DNS サーバーに転送するには、データセンターと DNS-VPC 間の接続が必要です。接続は、 Site-to-Site VPN または AWS Direct Connect を使用して確立できます。 ステップ 2: 参加アカウントを設定する 参加しているアカウントごとに、共有転送ルールを使用するように VPC を設定し、アカウントごとにプライベートホストゾーンを作成する必要があります。 AWS Resource Access Manager からの 共有ルールに同意 します。ルールが AWS 組織と共有されている場合、このステップは不要です。次に、転送ルールを各アカウントのワークロードをホストする VPC に関連付け ます。関連付けが完了すると、リゾルバーはルールに従ってDNSクエリの転送を開始します。 この時点で、共有転送ルールに関連付けられている任意の VPC で実行されているワークロードからオンプレミスドメインを解決できるはずです。AWS でプライベートドメインを作成するには、プライベートホストゾーンを作成する必要があります。 ステップ 3: プライベートホストゾーンを作成する このステップでは、awscloud.private のサブドメインを使用して各アカウントにプライベートホストゾーンを作成する必要があります。環境内でのドメインの競合を避けるため、プライベートホストゾーンごとに一意の名前を使用してください (たとえば、acc1.awscloud.private または dev.awscloud.privateなどです)。 awscloud.private のサブドメインを持つ各参加アカウントに プライベートホストゾーンを作成 し、そのアカウントで実行されている VPC に関連付けます。 プライベートホストゾーンを DNS-VPC に関連付け ます。これにより、集中管理された DNS-VPC はプライベートホストゾーンのドメインを解決し、AWS アカウント間の DNS リゾルバーとして機能できます。 プライベートホストゾーンと DNS-VPC は異なるアカウントにあるため、プライベートホストゾーンを DNS-VPC に関連付ける必要があります。そのためには、プライベートホストゾーンを所有するアカウントから認証を作成し、DNS-VPC を所有するアカウントからこの承認を受け入れる必要があります。これは AWS CLI を使用して行うことができます。 参加している各アカウントで、プライベートホストゾーン ID、リージョン、関連付ける VPC ID (DNS-VPC) を使用して認証を作成します。 aws route53 create-vpc-association-authorization --hosted-zone-id <hosted-zone-id> --vpc VPCRegion= <region> ,VPCId= <vpc-id> Text Central DNS アカウントで、参加している各アカウントのホストゾーンに DNS-VPC を関連付けます。 aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <hosted-zone-id> --vpc VPCRegion= <region> ,VPCId= <vpc-id> Text ステップ 4: オンプレミス DNS フォワーダーを設定する オンプレミスで実行されているワークロードから awscloud.private ドメイン内のサブドメインを解決できるようにするには、Central DNS アカウントに作成されたリゾルバーインバウンドエンドポイントの 2 つの IP アドレスにドメインクエリを転送する条件付き転送ルールを設定する必要があります。これには、データセンターと DNS-VPC 間の接続が必要であることに注意してください。接続には、 Site-to-Site VPN または AWS Direct Connect を使うことができます。 その他の考慮事項と制限事項 Route 53 Resolverの柔軟性と条件付き転送ルールにより、どのクエリを Central DNSに送信し、どのクエリを同じアカウントでローカルに解決するかを制御できます。これは、AWS PrivateLink や Amazon Elastic File System (EFS) など一部の AWS サービスを使用する予定がある場合に特に重要です。これらのサービスに関連するドメイン名は、それらを所有するアカウントのローカルで解決する必要があるためです。 可能であれば、アカウントのローカルドメインを解決することをお勧めします。たとえば、同じアカウントのプライベートホストゾーンにあるプライベートドメインの場合です。そのためには、アカウントのローカルに条件付き転送ルールを作成し、ルールタイプに「system」を使用して、これらのルールを VPC に関連付けることができます。 ※訳者注記：ルールタイプについてのドキュメントは こちら を参照ください。 Route 53 リゾルバーの制限に関する注意：Route 53 リゾルバーには、エンドポイントの IP アドレスあたり 1 秒あたり 10,000 クエリという制限があります。より高い制限を必要とするワークロードがある場合は、EC2 インスタンス上で実行されている適切に設定されたローカル DNS サーバーにこれらのクエリを転送することを検討してください。サービスの制限について詳しくは、 こちら をご覧ください。 このセクションでは、追加の考慮事項が必要な 2 つのユースケースを挙げます。 インターフェイス VPC エンドポイント (AWS PrivateLink) AWS PrivateLink インターフェイスエンドポイント を作成すると、AWS はサービスとの通信に使用できるエンドポイント固有の DNS ホスト名を生成します。AWS サービスと AWS Marketplace パートナーサービスでは、オプションでエンドポイントのプライベート DNS を有効にできます。このオプションは、プライベートホストゾーンを VPC に関連付けます。ホストゾーンには、サービスのデフォルト DNS 名のレコードセット (たとえば 、ec2.us-east-1.amazonaws.com) が含まれています。このレコードセットは、VPC 内のエンドポイントネットワークインターフェイスのプライベート IP アドレスになります。これにより、エンドポイント固有の DNS ホスト名ではなく、デフォルトの DNS ホスト名を使用してサービスにリクエストを行うことができます。エンドポイントにプライベート DNS を使用する場合は、アカウントのローカルエンドポイントへの DNS クエリを解決し、AWS が提供するデフォルトの DNS を使用する必要があります。そのため、この場合は 、amazonaws.com のドメインクエリをローカルで解決し、これらのクエリを Central DNS に転送しないことをお勧めします。 DNS 名を使用して EFS をマウントする DNS 名を使用して Amazon EFS ファイルシステム　Amazon　EC2　インスタンスにマウントできます。ファイルシステム　DNS　名は、接続している Amazon EC2 インスタンスのアベイラビリティーゾーンにあるマウントターゲットの IP アドレスに自動的に解決されます。そのためには、VPC は Amazon が提供するデフォルト DNS を使用して EFS DNS 名を解決する必要があります。ご使用の環境で EFS を使用する予定がある場合は、EFS DNS 名をローカルで解決し、これらのクエリを Central DNS に送信しないことをお勧めします。その場合、クライアントはアベイラビリティーゾーンに最適化された回答を受け取ることができず、オペレーションのレイテンシーが高くなり、耐久性が低下する可能性があります。 まとめ この記事では、マルチアカウントおよびハイブリッド環境で Central DNS 解決を実装するための簡単なソリューションを紹介しました。このソリューションでは、AWS Route 53 Resolver、AWS Resource Access Manager、および Route 53 のネイティブ機能が使用され、AWS　環境でカスタム　DNS　サーバーやフォワーダーが不要になるため、複雑さと運用の労力が軽減されます。 著者について Mahmoud Matouk Mahmoud は、世界各地の公共部門ソリューションアーキテクトの一員であり、高等教育機関のお客様がさまざまな AWS サービスを使用して、革新的で安全で可用性の高いソリューションを構築できるよう支援しています。 この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文は こちら です。

この記事は、 Commoditize connected mobility with WirelessCar on AWS を翻訳したものです。 WirelessCar は、スウェーデン、米国、中国に拠点を置き、12 社以上の自動車 OEM 、世界中の 100 を超える市場 に対して、 AWS の 99.99% の稼働率でコネクテッドモビリティサービスを提供しています。WirelessCar は、コネクテッドカーサービスの構築において 20 年以上の経験を持つ AWS パートナー です。WirelessCar は、API 製品、コストの最適化、フライホイールの構築、AWS によるスケールメリットにより、AWS 上のコネクテッドモビリティサービスをコモディティ化してきました。WirelessCar が AWS 上で展開するプラットフォームには、現在 1,000 万台以上の車両が接続しており、 1 億台の接続数であれば、年間の台あたりコストを 1 桁ドル台まで下げるに至っています。 このブログ記事では、WirelessCar が AWS を利用してモジュラー API 製品を構築し、コスト最適化を実現し、スケールメリットを構築してコネクテッドモビリティサービスをコモディティ化した方法に焦点を当てています。 背景 自動車 OEM がデジタルトランスフォーメーションを続けるにつれて、ソフトウェア開発組織になりつつあり、ソフトウェアサプライヤーからのサービスの利用方法も変化するでしょう。要件を指定してサプライヤーに機能を注文する組織から、社内で独自のソフトウェアを構築する開発チームへと変化しています。誰もが毎回すべてをゼロから構築することは持続可能ではないため、チームは差別化のない機能をサプライヤーから購入することに頼っています。このようなソースソフトウェアの消費者が OEM の社内開発チームに移るとき、彼らはパブリッククラウドサービスと同じようにソフトウェアを利用できることを期待しています。つまり、自分でインストールして運用する必要のあるソフトウェアパッケージを受け取ることは期待せず、 SaaS モデルでサプライヤーから提供された API ベースの製品を利用することになります。これにより、 OEM 開発チームはセルフサービスで製品のインスタンス化、統合のトラブルシューティング、使用状況と請求のフォローアップ、アクセスとデータの管理を行うことができます。その結果、ボトルネックが解消され、 OEM はイノベーションのスピードを上げることができます。 WirelessCar の API 製品 WirelessCar は、クラウドベースのフルマネージド型コネクテッドモビリティ API 製品を SaaS 方式で提供します。既製のマネージド API 製品を自社で構築して保守する代わりに利用することで、OEM は差別化機能の提供に注力し、総所有コストを削減し、スケールメリットを享受できます。カスタマイズやコンサルティングのニーズに合わせて、 WirelessCar はプロフェッショナルサービスとディスカバリーサービスを提供します。OEM は、顧客にコネクテッドモビリティサービスや、 API を使用して採用して既存のプラットフォームに統合したい製品を提供するために、WirelessCar 製品スイート全体を完全なソリューションとして採用することを選択します。そのため、既存のOEM プラットフォームと新しい OEM プラットフォームの両方が、 WirelessCar API 製品のすべてまたは一部を採用しています。 WirelessCar は、コネクテッドモビリティの6つの異なる分野で API 製品を提供しています。 接続性 : 車両とライフサイクル管理への接続を提供する製品。 ジャーニーインテリジェンス : この分野には、 位置と移動の統計情報 、 データレイク 、デジタルコンパニオン、ドライバーモニタリング、コーチングのユースケースを網羅した製品が含まれます。 安全とセキュリティ : これには、 コールセンターサービス 、盗難車追跡、車両セキュリティ警告サービスが含まれます。 電気自動車 ( EV ) : 自動車業界で信頼性の高い EV サービスの1つであるスマート EV ルーティング、スマート充電、デジタル EV コンパニオンサービス。 共有モビリティ : この分野では、WirelessCar が車両管理、車両データアクセス、デジタル管理サービスを提供します。 デジタルトランスフォーメーション : 物流追跡、社用車管理、遠隔診断、予知保全などがこの分野でカバーされる最新のサービスです。 WirelessCar と AWS は協力して、エッジ・ツー・クラウド、セキュリティ、データ、機械学習などの分野で新製品を開発しています。OEM は WirelessCar サービスを採用し、WirelessCar サービス API を使用してその上にサービスを構築しています。 WirelessCar 製品は、OEM が車両、工場、顧客関係管理システム、またはその他のエンドポイントからデータを安全に取り込むのに役立ちます。OEM は WirelessCar に連絡してこれらの API を購読します。WirelessCar には、API の使用方法に関する詳細なドキュメントが用意されています。OEM は、サービスの利用に何か月も何年もかかっていた API を数週間で使い始めています。 WirelessCar 製品は、AWS のマネージドサービスと Amazon API gateway 、 AWS Lambda 、 Amazon DynamoDB 、 AWS IoT Core などの Serverless サービスを使用して、インフラストラクチャをコスト効率よくスケーリングし、DevOps の労力を削減します。WirelessCar サービスをコードとしてのインフラストラクチャとして構築し、継続的インテグレーションと継続的デプロイ ( CI/CD ) パイプラインを構築することで、DevOps の労力が軽減されます。ロギング、モニタリング、アラートサービスは Amazon CloudWatch を使用して提供されます。セキュリティとアクセス管理を確保するために、AWS のセキュリティおよびアクセス管理サービスである Identity and Access Management (IAM) 、 AWS WAF 、 AWS Certificate Manager (ACM) 、 AWS security hub 、 AWS Shield 、およびその他のサービスが使用されています。このように、WirelessCar はコネクテッドモビリティサービスを利用するためのモジュール式 API 製品を OEM に提供しています。AWS と WirelessCar は、今後、これらのサービスを AWS マーケットプレイスで利用できるように取り組んでいます。これにより、誰でも既製の WirelessCar 製品を使い始めることができます。 コスト最適化 コスト最適化は一過性のものではなく、費用対効果の高いソリューションを開発するために企業文化の一部として DevOps チームに組み込まれます。モビリティワークロードにおけるコストは、車両の通信パターン、車両が使用するモビリティサービスの数、および車両が要求する応答によって異なります。これら 3 つのパラメータは OEM ごとに異なるため、各 OEM のコストは異なります。このためコスト最適化は、 OEM プログラム、 WirelessCar サービス、および AWS サービスごとのコストを特定することからスタートしました。 WirelessCar と AWS は、コストログと Amazon QuickSight を使用してコストを見える化し、1 台あたりの年間コスト、メッセージあたりのコストなどのマトリックスを作成しました。現在では WirelessCar は、コストをほぼリアルタイムで追跡し、結果を測定することが可能となりました。 WirelessCar では、コストの視覚化を可能にするために、すべての AWS リソースに対して一貫したタグ付け戦略を採用していることに注意してください。 WirelessCar は、2 つの方法でコスト削減を実現しました。 アーキテクチャ変更したり、多大な労力をかけたり、クラウド利用に関するガバナンスを設定したりすることのないような、容易な項目を特定しました。例えば、未使用のリソースやデータのクリーニング、コスト削減のための IO2 から IO3 への Amazon Elastic Block Store ( Amazon EBS ) ボリューム変更や、コンピューティングとデータベース用の AWS EC2 Graviton インスタンスの利用などです。 各 AWS サービスの使用方法を確認し、コスト最適化アクションとリファクタリングを特定しました。これらの取り組みは、 WirelessCar チームが各スプリントで計画し、機能の実装を優先しながら、時間をかけて実施してきました。 WirelessCar におけるコスト最適化キャンペーンにより、WirelessCar チームは自分たちの選択を意識するようになりました。現在、 WirelessCar チームは開発したサービスコストを QuickSight で追跡し、コストの最適化に取り組んでおり、また WirelessCar のお客様はこれらのコスト削減から直接メリットを得ることができます。このように、 WirelessCar はコスト効率の高い API 製品を OEM に提供しています。 スケールメリットの構築 20 年以上の経験、コストを最適化した優れた API 製品、 AWS とのパートナーシップ、市場開拓戦略により、 WirelessCar の製品を利用する OEM の数はますます増えています。 WirelessCar は、数か月や数年ではなく、数週間で顧客をプラットフォームに導入できるようになりました。既存のモビリティプラットフォームは、特に EV サービスの分野でギャップを埋めるために WirelessCar サービスを採用しています。 WirelessCar と AWS は協力して新しいサービスを市場に投入しています。 これにより、世界中で毎週何千台もの新しい車両が WirelessCar 製品に接続されています。これはフライホイールの構築とスケールメリットの向上に役立ち、ひいては車両1台あたりのコストを削減し、 WirelessCar のお客様にもメリットをもたらします。私たちは 1 億台の車両に搭載し、コネクテッドモビリティサービスを共同でコモディティ化することを目指しています。 最後に このブログ記事では、 WirelessCar と AWS がどのように協力して API 製品、コスト最適化、スケールメリットを利用してコネクテッドモビリティサービスをコモディティ化したかを学びました。詳細については、 WirelessCar まで お問い合わせ ください。AWS サービスの詳細については、 自動車向け AWS のページ をご覧ください。または、今すぐ AWS チームに お問い合わせ ください。 このブログは、ソリューションアーキテクトの丹羽と小野田が翻訳しました。 Sushant Dhamnekar Sushant Dhamnekar は AWS のシニアソリューションアーキテクトです。Sushant は、信頼できるアドバイザーとして、コネクテッドモビリティやソフトウェアデファインドビークルの分野で、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャを構築する自動車業界のお客様を支援しています。仕事以外では、Sushantはハイキング、食事、旅行、HIT ワークアウトを楽しんでいます。 Tomas Carlfalk トーマスは、コネクテッドカーのパイオニアである WirelessCar の CTO であり、自動車メーカーと協力してデジタルトランスフォーメーション戦略を実現しています。スウェーデン西海岸のヨーテボリで生まれ育ったトーマスは、約20年前に WirelessCar のソフトウェア開発者として自動車業界でキャリアをスタートさせました。長年にわたり、さまざまな役職でコネクテッドカープログラムの立ち上げに携わってきたほか、 WirelessCar 全体のクラウド導入とサイバーセキュリティの取り組みを主導してきました。

最近は日本政府および多くの企業が「クラウド・ファースト」を宣言し、クラウドを最優先にシステム開発に取り組む事例が数多く出てきています。業界や規模を問わず多くの企業が、クラウド上でシステムを開発するプロジェクトに取り組んでいます。クラウドを活用する場合でも、プロジェクト管理のポイントは従来のプロジェクトと変わらず、PMBOK® Guide等のナレッジを最大限活用して進めることが重要です。一方で、クラウドの特性ゆえに陥りがちな問題もあり、回避策を知り正しく実践することでプロジェクトの成功率を高めることができます。 そこで、著者がカスタマーソリューションマネジャーとしてお客様を支援する中で得られた、クラウドを活用するプロジェクトを進める際の具体的な考慮点を、複数回に分けてお伝えいたします。初回となる本ブログでは、プロジェクトの立ち上げにフォーカスし、目標とするビジネス価値を明確にして関係者と合意することの重要性について記載します。クラウドを活用したプロジェクトの立ち上げをリードする方を主な読者と想定していますが、プロジェクトメンバとして実行に関わる方にも参考になる内容と考えています。 クラウドを活用するプロジェクトで起こりやすい問題 クラウドを活用するプロジェクトは「クラウドの活用」自体が目的となり、具体的なビジネス上の目標が不明確なまま開始されてしまうことがあります。それにより、以下のような問題が発生し、プロジェクトの減速・停滞につながってしまうケースが見られます。 想定外の問題が発生した時や、他の重要案件が発生した時にプロジェクトの優先度を正しく評価できず劣後・停滞してしまう システムのリリース後にコストの削減のみが注目され、「期待していた効果が出ていない」と評価される。またはそもそも効果の評価自体ができない状態となる このような状況を避けるためには、以下2点を注意してプロジェクトを立ち上げることが重要です。 考慮点①　クラウド活用で得られる価値を正しく理解し、具体的なビジネス上の目標を設定する クラウドを活用することで得られる価値は多岐にわたります。以下にAWSがこれまで多数・多様なお客様のクラウド移行をご支援する経験に基づいて整理した、クラウドの活用により期待できる価値のフレームワーク（ AWS Cloud Value Framework ）を記載しています。もちろん実際に期待できる価値は各システムの特性や状況にもよりますが、システムの信頼性向上や俊敏性向上がコスト削減以上にビジネスに大きな価値をもたらすことも多くあります。 そのため、プロジェクト立ち上げの際に、これらを踏まえた広い視点で具体的なビジネス上の目標を定義し、検証できるよう準備をすることが非常に重要となります。そうすることで、想定外の問題が発生した時や、他の重要案件が発生した時に客観的な評価をすることが可能となり、プロジェクトの減速・停滞を防止することができます。また、システムリリース後に効果の計測・評価を適切に行うことも可能となります。 考慮点②　ビジネス部門を含めたプロジェクトのステークホルダー全員で目標を合意する 具体的なビジネス上の目標を立てているものの、ステークホルダーの特定や重要度判断が不足することで、ビジネス部門との認識が合致していないケースが見られます。このような状態では、プロジェクトを進める中で、仕様変更の判断が正しくできない、テストや移行準備などで適切な協力が得られない、といった問題につながってしまいます。 そのため、設定した目標をプロジェクトのステークホルダー全体に共有し、合意しておくことが非常に重要です。プロジェクトマネージャーにはこの点を意識し、必要なコミュニケーションを丁寧に行うことが求められます。加えて、合意した内容は極力プロジェクト憲章等に文章化して残すことが推奨されます。それにより、認識相違の防止や、プロジェクトメンバへの共有の効果が高まります。 また、クラウド活用推進をミッションとした、ビジネス部門とIT部門が一体となった組織（CCoE：Cloud Center of Excellence）がプロジェクトの立ち上げを支援することも有効な方法となります。CCoEについてはその役割等を解説している ブログ を是非参考にしていただければと思います。 まとめ クラウド活用プロジェクトを成功に導くためには、プロジェクト立ち上げの時点で達成すべきビジネス価値を明確にし、関係者間で合意することが重要です。具体的には、以下の2点に注意しましょう。 クラウド活用の価値を広く理解し、具体的なプロジェクトの目標を設定する ビジネス部門を含めたステークホルダー全員で目標を合意する プロジェクト立ち上げ後の重要な考慮点については、次回以降のブログでお伝えいたしますので、そちらも是非ご覧ください。 参考リンク 第１回：プロジェクトの立ち上げ 第２回：柔軟なベースライン管理

第２回ではプロジェクトを成功させる３大要素である、スコープ、スケジュール、コストのベースラインに焦点を当てます。プロジェクトの成功に向けて成果物を明確に定義し、範囲を制御するスコープ管理、プロジェクトを所定の時期に完了するようマネジメントするスケジュール管理、プロジェクト予算内で運営するためのコスト管理は不可欠な管理領域です。これらの管理領域は密接に連携し、バランスを保ちながらプロジェクトを計画、実行し、監視する必要があります。また、開発アプローチについては、プロジェクトの要求事項や環境に応じて適切なアプローチ手法を選択する必要があります。本ブログでは、伝統的なウォーターフォール開発だけでなく、クラウドの特性を最大限に活用するために、アジャイル開発やハイブリッド開発などの柔軟な開発アプローチも考慮し、お客様へクラウド活用をご支援する中で得られた具体的な考慮点をご紹介します。 多様なサービスの活用や柔軟なスケーリングができるメリットを活かしたスコープ管理 スコープ管理はプロジェクトの範囲を明確に定義し、変更を管理する重要な要素です。クラウド導入プロジェクトにおけるスコープ管理では、以下の内容について考慮することが重要です。 柔軟なスコープ変更への対応 ：クラウドの利点である多種多様なサービスを低コスト、短時間で利用できる特徴に注目し、ビジネスニーズや市場変化に適応するための柔軟なスコープ変更を可能にする対応策が求められます。これには、適切なスコープ変更プロセスの確立が必要であり、新しいサービスの追加や既存のサービスの削減などを戦略的かつ迅速に実現できるようになります。柔軟なスコープ変更は、競争力維持・向上やビジネスの成功に寄与し、クラウド導入プロジェクトの成果を最大限に活用する手段となります。 マネージドサービスの活用 ： マネージドサービス を利用することで、スプリントごとにスコープ調整が行われる際などに、リソースの設定や運用、スケーリングにおいて柔軟性と効率性を提供することが可能になります。マネージドサービスは、セキュリティやパフォーマンスの向上を支援し、リソースの最適な利用を確保します。スコープの変更に伴う新たな要件に対応し、リソースを迅速かつ適切に調整する際に、貴重な時間とリソースを節約できます。これにより、システムやプロダクトの柔軟性を高め、効率性を向上させることが可能となります。 アジャイル開発およびPoCの早期実施を活用したスケジュール管理 スケジュール管理は、プロジェクトの進捗を計画し、タスクや活動を時間的に配置する重要な要素です。クラウド導入プロジェクトにおけるスケジュール管理では、以下の内容について考慮することが重要です。 アジャイル開発の活用 ：クラウドは短期間で機能を構築できる特性を持ちます。開発手法としてウォーターフォール開発だけで進めるのではなく、 アジャイル開発 やハイブリッド開発を採用することで、スケジュールを柔軟に調整でき、ビジネス要件や市場の変化に素早く対応できます。アジャイルのイテレーションと迅速な反応性により、プロジェクトの進行状況を継続的に改善し、新たな要求事項を迎え入れる柔軟性が生まれます。これにより、プロジェクトの成功確率が向上し、リソースの最適活用とスケジュールの合理的な達成が実現できます。アジャイル開発は、クラウド導入プロジェクトの効果的なスケジュール管理はもちろんのこと、柔軟なベースライン管理全般に貢献します。 PoC（Proof of Concept）の早期実施 ：クラウドの特性を活用し、実際の環境でのPoCは机上検証よりも有益です。早い段階で実環境を用いたPoCを行うことで、システムやアプリケーションの適合性やスケジュールの実現性をより早く、確実に確認できます。これにより、問題や課題を早期に発見し、修正できるため、プロジェクトの進行におけるリスクを最小化できます。PoCの早期実施は、クラウド導入プロジェクトの成功に向けたスケジュール管理戦略の重要な要素であり、計画の実現可能性を向上させます。 クラウドの特徴を活かす柔軟なコスト管理 コスト管理はプロジェクトにかかる費用が予算内に収まるよう効果的に管理する重要な要素です。クラウド導入プロジェクトにおけるコスト管理では、以下の内容について考慮することが重要です。 リソース配置の最適化と過剰なリソース割当の回避 ：クラウドは必要なリソースを必要なタイミングで提供できる特性を備えています。このため、過剰なリソース割当を防ぐために、必要な時にのみリソースを起動し、利用しない時はリソースを停止するなど、クラウドの柔軟性を最大限に活用したコスト管理が肝要です。これにより、不必要なコストを削減し、プロジェクトのコスト効率を向上させることができます。また、リソースのモニタリングと適切なスケジュールの設定により、コストを最小限に抑えながら、プロジェクトの成功を支えることができます。 コストの柔軟な管理と関係者の合意 ：クラウドを活用したプロジェクトでは、開発進捗、試行検証、仕様変更等によるコストの変動が予想されます。このため、厳密な予算遵守よりも柔軟なコスト管理が必要です。状況に応じて予算を調整し、 コスト最適化 に向けて、事前に関係者との合意を得ることが重要です。合意を得ることで、プロジェクトの進行への影響を回避するために、予算変更やリソースの調整がスムーズに実施できます。この柔軟なアプローチは、クラウド導入プロジェクトにおいて予測困難な状況に、迅速に対処するための重要な手段であり、関係者の協力と合意を得ることで、コスト管理の効果を高めます。 まとめ クラウド導入プロジェクトにおいて、クラウド活用の真価である価値創造により集中するために、柔軟なスコープ変更に対応可能なコスト管理、アジャイル開発やPoC等を積極的に活用したスケジュール管理、リソースの最適配置による柔軟なコスト管理を含んだ、柔軟なベースライン管理が重要です。これらの要素は、プロジェクトの効率化と成功に焦点を当て、価値を最大化します。本ブログで整理した考慮点を参考に、クラウド導入プロジェクトの成功につなげていただければ幸いです。 参考リンク 第１回：プロジェクトの立ち上げ 第２回：柔軟なベースライン管理

この記事は Serverless containers at AWS re:Invent 2023 (記事公開日: 2023 年 11 月 9 日) を翻訳したものです。 AWS re:Invent は、AWS によるクラウドコンピューティングに関する世界規模の「学習型」カンファレンスです。今年は、 Amazon Elastic Container Service (Amazon ECS) と AWS Fargate のサービスチームが、生産性の向上、コストの最適化、ビジネスの俊敏性の向上に役立つベストプラクティスやヒントを共有します。ぜひ 11 月 27 日から 12 月 1 日まで (PST: 米国太平洋標準時)、ラスベガスにてご参加ください。 Expo ホール の Amazon ECS キオスクまたは AWS モダンアプリケーションとオープンソースゾーン にいらしてください。AWS でのモダンアプリケーションの構築についてエキスパートに質問したり、デモンストレーションを見たり、またオープンソースチームと会うことができます。ぜひお立ち寄りいただき、挨拶を交わし、楽しんで、おやつを食べて、クレーンゲームマシンから賞品を獲得しましょう！ 参加型セッション 例年同様、カンファレンスではさまざまな形式でのセッションが提供されます。 ブレイクアウトセッション：AWS のエキスパート、開発者、お客様による講義形式のプレゼンテーションです。 ワークショップ：新しいテクノロジーを学ぶのに役立つハンズオン形式での学習セッションです。参加には自身のラップトップを持参してください。 チョークトーク：さまざまなトピックのエキスパートによる対話形式のセッションです。ぜひ自分の経験やフィードバックを共有してください。 開発者向けセッション：AWS のエキスパートが主導する小規模なセッションで、自身のラップトップでプロジェクトを構築します。 ブレイクアウトセッション CON205 | Amazon ECS でビジネスアプリケーションを強化しよう 11 月 28 日 (火) 9:00 am JST | (Nov 27, 4:00 pm PST, Caesars Forum, Level 1, Summit 214) Amazon ECS はフルマネージドのコンテナオーケストレーションサービスで、安全性、信頼性、拡張性に優れたコンテナをよりシンプルに実行できます。Amazon ECS の GM であるNick Coult が、重要なビジネスアプリケーションを Amazon ECS を使用することでどのように強化できるかについて説明します。Amazon ECS と AWS Fargate の最新の進歩について学び、モダナイゼーションの目標をより迅速に達成するのにお役立てください。また、ユナイテッド航空が Amazon ECS を使用してどのようにモノリシックなアプリケーションをマイクロサービスに移行し、アプリケーションをモダナイズして目覚ましい成果を上げたかをご覧ください。 CON320 | AWS のサーバーレスサービスで未来を構築する 11 月 30 日 (木) 6:00 am JST | (Nov 29, 1:00 pm PST, Wynn, Level 1, Lafite 4) AWS のサーバーレスサービスは、企業がアイデアを本番環境に出すまでの道のりを短縮し、最新のアプリケーションを大規模に構築して実行できるようにすると同時に、コストを削減して俊敏性を高めるのに役立ちます。企業がビジネスで優れた成果を達成するのを支援するために、AWS がサーバーレスコンピューティングとコンテナで行っているイノベーションについて AWS のサーバーレスコンピューティングのバイスプレジデントである Holly Mesrobian が話します。 AWS Lambda 、 Amazon EventBridge 、 AWS Step Functions 、Amazon ECS on AWS Fargate などにおける新たな進歩や最近のリリースについて学んでください。企業が AWS の運用上の優位性を活用して、近代化の目標をより迅速に達成できる方法を学びましょう CON209 | AWS App Runnerによるコストとパフォーマンスの最適化 12 月 1日 (金) 09:00 am JST | (Nov 30, 4:00 pm PST, Wynn, Level 1, Lafite 9) コンピューティングコストは、企業がワークロードをどこにどのようにデプロイするかを評価する一般的な検討項目です。このセッションでは、 AWS App Runner のフルマネージド機能を使用して、総所有コストを削減し、アプリケーションの俊敏性を向上させる方法を紹介します。このセッションでは、自動スケーリング、継続的デプロイ、マネージドランタイムバージョンについて説明します。AWS App Runner が行うコードからのデプロイや、インフラストラクチャの管理、オーバーヘッドの削減方法の具体例をご覧ください。さらに、AWS App Runner によるパフォーマンスチューニングに関するエキスパートのガイダンスを受けて、アプリケーションの効率的な実行を支援します。 CON303 | サーバーレスコンテナを使用した生成系 AI アプリを大規模かつ効率的にデプロイ 11 月28 日(火) 10:30 am JST | (Nov 27, 5:30 pm PST, Caesars Forum, Level 1, Forum 113) さまざまなビジネスユースケースの課題を解決するために、LLM モデルの導入を検討する企業が増えています。このセッションでは Amazon ECS on AWS Fargate での CPU 推論、Amazon ECS on Amazon Elastic Compute Cloud (Amazon EC2) での GPU と Inf1 による高速推論、および関連するストレージとネットワーキングのオプションなど、Amazon ECS を使用して LLM モデルをデプロイするのに役立つさまざまなインフラストラクチャオプションと統合について説明します。 CON307 | コンテナイメージの遅延読み込みによる AWS Fargate の起動時間の短縮 11 月 29 日(水) 4:00 am JST | (Nov 28, 11:00 am PST, Mandalay Bay, Level 3, South, Jasmine H) このセッションでは、Seekable OCI (SOCI) について Dive Deep します。AWS Fargate で SOCI インデックスを使用することで、Amazon ECS タスクの起動にかかる時間を大幅に短縮する方法をご覧ください。SOCI のベストプラクティスについて学び、適切なワークロードに SOCI を利用する方法を学び、既存の OCI コンテナイメージの SOCI インデックス作成を自動化するさまざまな方法を検討します。 CON313 | Amazon ECS と AWS Fargate へのマルチテナント SaaS アプリケーションのデプロイ 11 月 28 日 (火) 07:30 am JST | (Nov 27, 2:30 pm PST, Caesars Forum, Level 1, Forum 121) Amazon ECS で SaaS ソリューションを構築する傾向が高まっています。マルチテナントの SaaS アプリケーションを開発する際には、テナントの分離、テナントのオンボーディング、テナント固有のメータリング、監視、その他 SaaS に必要な側面など、複数の問題に対処する必要があります。このセッションでは、AWS Fargate にソリューションをデプロイする際にマルチテナントをどのように管理するかを探ります。 CON315 | Data-Aware アプリケーションを大規模に展開するためのストレージオプションの進歩 12 月 1 日 (金) 07:00 am JST | (Nov 30, 2:00 pm PST, MGM Grand, Level 1, Grand 120) 企業がコンピューティングにコンテナを幅広く採用しようとしている中、ビッグデータや ETL ジョブなどの一部のワークロードでは、既存のデータを取得して処理を実行し、処理されたデータをダウンストリームで使用できるように保存する必要があります。コンピューティング効率を最大化するために、これらのワークロードには大量のトランザクションとスループットをサポートするストレージが必要です。このセッションでは、基盤となるストレージの管理について心配することなく、データ処理とストレージを大量に消費するワークロードを大規模に実行する方法を詳しく見ていきます。 CON318 | 効率性の向上: AWS Fargate で 70% のコスト削減を実現する方法 11 月 29 日 (水) 07:30 am JST | (Nov 28, 2:30 pm PST, Mandalay Bay, Level 3, South, South Seas E) このセッションでは、大手エンタープライズ SaaS 企業が AWS Fargate と AWS Graviton を使用して、データ集約型のグリッドサービスをどのように変革したかをご覧ください。6 か月以内に 70% のコスト削減を実現し、ピーク時のトラフィックを 1,000 RPS から 50,000 RPS に増やしました。また AWS CodePipeline を使用して、デプロイ速度を週 1 回から毎日 2 回に増やした方法をご覧ください。拡張性と効率を向上させるためのセルベースのアーキテクチャ戦略をご覧ください。 CON322 | AWS Fargate への移行による TCO とダウンタイムの削減 11 月 30 日(木) 10:30 am JST | (Nov 29, 5:30 pm PST, Wynn, Level 1, Lafite 4) 大規模な金融サービス企業を含む多くの企業が、大規模なアプリケーションのモダナイゼーションを通じてクラウド対応のイノベーションの真っ只中にいます。これらの企業は、アプリケーションの拡張性、セキュリティ、運用効率を犠牲にすることなく、総所有コスト (TCO) を削減したいと考えていることがよくあります。このセッションでは、複雑な組織が段階的にサーバーレスコンテナに移行し、コスト負担を徐々に軽減するために利用したさまざまな方法 (AWS Fargate など) について説明します。規制の厳しい環境で全体的なコストを削減するために使用できるアーキテクチャ上の重要な決定事項とベストプラクティスについて説明します。 CON325｜Amazon ECS と AWS Fargateでコンテナ化されたワークロードを保護する 12 月 01 日 (金) 04:30 am JST | (Nov 30, 11:30 am PST, Wynn, Level 1, Lafleur 2) この本セッションでは、Amazon ECS と AWSクラウドの統合、AWS のセキュリティサービスの利用、AWS Fargate のシングルテナンシーアーキテクチャのメリットなど、コンテナ化されたワークロードを安全に実行するための概要を説明します。AWS Fargate のセキュリティに関する考慮事項に Dive Deep し、AWS Fargate の最新機能を使用して潜在的な脅威やイベントに対するセキュリティ体制を改善する方法を見つけてください。 CON401 | Amazon ECS のレジリエンスと可用性を深く掘り下げる 11 月 30 日 (木) 02:30 am JST | (Nov 29, 9:30 am PST, Mandalay Bay, Level 1, North, Islander G) すべてのアプリケーションのアーキテクチャは、基盤となるインフラストラクチャに依存しています。多くのアプリケーションアーキテクチャの基盤として Amazon ECS が選択されています。Amazon ECS がどのように構築されているか知っていますか? サービスを構築する際には、どのような設計上の考慮事項が必要ですか? Amazon ECS はシステム停止を最小限に抑えるのにどのように役立ちますか? このセッションでは、耐障害性と信頼性の高いアプリケーションをクラウドで実行するための要件に Amazon ECS がどのように対応できるかを学びます。Amazon ECS サービスのアーキテクチャ、設計、オペレーション方法が、アプリケーションの安全で回復力のある基盤をどのように提供しているかについて Dive Deep します。 ENT212 | Carrier Global が AWS 上の Windows コンテナで 40% の節約を実現した方法 12 月 1 日(金) 05:30 am JST | (Nov 30, 12:30 pm PST, MGM Grand, Level 3, Chairmans 370) このセッションでは、Carrier Global が AWS テクノロジーを使用して、レガシーな .NET コードをリファクタリングなしで最新のイベント駆動型アプリケーションに変換した方法について学びます。Amazon ECS 上の Windows コンテナを使用してアーキテクチャの最新化を実現し、機能提供の俊敏性を向上させた方法をご覧ください。また、Carrier Global がさまざまな AWS のサービスと機能を使用して Windows アプリケーションの実行コストを 40% 削減し、スケーリングのパフォーマンスを 70% 向上させた方法についても説明します。 チョークトーク (対話型セッション) CON314 | Amazon ECS によるモダンアプリケーション開発の高速化 11 月 29 日 (水) 07:30 am JST | 12 月 2日 (土) 03:30 am JST | (Nov 28, 2:30 pm PST, MGM Grand, Level 3, 301 | Dec 1, 10:30 am PST, Caesars Forum, Level 1, Forum 126) ベストプラクティスに基づいてアーキテクチャを構築することで、企業はパフォーマンスが高く、コスト効率が高く、安全なアプリケーションを構築できます。このチョークトークでは、 AWS Well-Architected Tool Framework に基づいた Amazon ECS のベストプラクティスについての洞察を提供します。Framework の各柱の重要なベストプラクティスを確認した後、ホワイトボードの例を通じて、これらのベストプラクティスが実際に Amazon ECS ワークロードにどのように適用されているかを確認してください。 CON316 | Amazon ECS オートスケーリング Deep Dive 11 月 28 日 (火) 07:30 am JST | 11 月 30 日 (木) 12:00 pm JST | (Nov 27, 2:30 pm PST, Caesars Forum, Level 1, Forum 104 | Nov 29, 7:00 pm PST, Caesars Forum, Level 1, Forum 123) オートスケーリングは、Amazon ECS サービス内の必要なタスク数を自動的に増減する機能を提供する Amazon ECS の強力な機能です。このチョークトークでは、キャパシティプロバイダーなどの Amazon ECS のオートスケーリングメカニズムと、Amazon EC2 と AWS Fargate を対象とした、ターゲット追跡ポリシーやステップスケーリングポリシーを含む Amazon ECS サービスのオートスケーリング について学びます。さまざまなワークロードに特化したさまざまなメトリクスを使用して、Amazon ECS のオートスケーリングオプションを指定する実際の使用例について説明します。 CON317 | Amazon ECS ネットワーキング Deep Dive 11 月 30 日 (木) 05:00 am JST | (Nov 29, 12:00 pm PST, MGM Grand, Level 3, Premier 320) このチョークトークでは、さまざまなネットワークモードや、Amazon ECS Service Connect と Amazon ECS サービスディスカバリーを使用した Amazon ECS サービス間のネットワーキングなど、Amazon ECS のネットワークメカニズムについて Dive Deep します。 Amazon ECS on Amazon EC2 と Amazon ECS on AWS Fargate を使用した ENI トランキングと、セカンダリ CIDR を使用した IP 枯渇のような実際のユースケースと一般的な問題、およびそれを解決するさまざまな方法を聞くことができます。この講演では、AWS PrivateLink を使用した接続の実装とその利点についても説明します。 CON319 | AWS Fargate と AWS Lambda による生成系 AI のデータパイプラインの構築 11 月 30 日 (木) 03:00 am JST | (Nov 29, 10:00 am PST, MGM Grand, Level 3, 304) 生成系 AI アプリケーションの人気が高まるにつれ、リアルタイムデータとスケーラブルな計算能力が基盤モデルの構築の中核となり、さまざまな業界のビジネスの急速な発展を後押ししています。このチョークトークでは、特にコンテナ、サーバーレス、統合されたサービスにおけるデータとコンピューティングに焦点を当てています。次世代アプリケーションを構築するためのユースケースとサーバーレスおよびコンテナサービスの効果的な活用方法を探ります。実際のユースケースについて聞き、イベント駆動型アーキテクチャやサーバーレスストリーム処理などのさまざまなパターンと、 Amazon EMR がどのようにアプリケーションの操作を大幅に簡素化および自動化できるかを確認してください。 CON321 | コンテナ化されたワークロードを AWS Fargate に移行する 11 月 29 日 (水) 06:00 am JST | (Nov 28, 1:00 pm PST, Caesars Forum, Level 1, Summit 221) AWS Fargate は、企業がコンテナワークロードのデプロイとモニタリングのオペレーション負担を軽減し、アプリケーションの構築とビジネスの運営に集中できるようにします。このチョークトークでは、Amazon EC2 から Amazon ECS 上で稼働する AWS Fargate サーバーレスコンピューティングにワークロードを移行する際の設計上の考慮事項について説明します。 CON323 | AWS Fargate サーバーレスアプリケーションのオブザーバビリティの実装 11 月 29 日 (水) 09:00 am JST | (Nov 28, 4:00 pm PST, MGM Grand, Level 3, Premier 320) AWS Fargate でコンテナ化されたワークロードが拡張するにつれて、効果的なオブザーバビリティを維持することはますます困難になっています。このチョークトークでは、AWS Fargate へのデプロイでオブザーバビリティをスケーリングするための戦略とベストプラクティスを検討します。メトリクスの収集、ログの集約、分析の最適化など、モニタリングとロギングを大規模に管理する方法をご紹介します。コンテナ中心のモニタリング手法、効率的なログ管理、および Amazon CloudWatch Logs、AWS Lambda、 AWS Glue などの AWS サービスの活用方法について詳しく説明します。 CON336 | AWS App Runner を使用して、ゼロから本番環境にアプリケーションを数分で作成する 12 月 1日 (金) 08:30 am JST | (Nov 30, 3:30 pm PST, Mandalay Bay, Level 1, North, South Pacific D) AWS App Runner を利用し、既存のアプリケーションを本番環境へ数分で変換する方法をご紹介します。このチョークトークでは、デプロイメント戦略、ネットワーク管理、秘密情報と設定の安全な取り扱いにおけるベストプラクティスを順守しながら、コンテナ化とデプロイのシームレスなプロセスをガイドします。AWS App Runner によって、アプリケーションを簡単に最新化し、AWS クラウドインフラストラクチャの潜在能力を最大限に活用して、市場投入までの時間と運用のオーバーヘッドを削減する方法をご覧ください。AWS App Runner を活用して、ゼロから本番環境に対応したアプリケーションへの移行を加速させましょう。 CON407 | Amazon ECS サービスのデプロイのベストプラクティス 11 月 29 日 (水) 06:00 am JST | (Nov 28, 1:00 pm PST, Caesars Forum, Level 1, Academy 411) Amazon ECS サービスを使用して、アプリケーションをコンテナ化されたマイクロサービスとして実行する組織が増えています。このチョークトークでは、Amazon ECS を使用して新しいアプリケーションバージョンを安全かつ迅速にロールアウトするためのベストプラクティスを共有することに重点を置いています。説明には、Amazon ECS のデプロイに使用できるさまざまなツール ( AWS CloudFormation 、AWS CDK、Terraform、AWS コマンドラインインターフェイス ( AWS CLI )、 AWS マネジメントコンソール など) と、アプリケーションのタイプ (負荷分散型またはイベント駆動型) とインフラストラクチャプロバイダー (Amazon EC2 または AWS Fargate) に応じて使用できる保護手段のベストプラクティスが含まれます。 CON408 | Amazon ECS と AWS Fargate を使用してワークロードのスピードとコストの最適化 11 月 29 日 (水) 10:30 am JST | 11 月 30 日 (木) 09:30 am JST | (Nov 28, 5:30 pm PST, Wynn, Level 1, Latour 5 | Nov 29, 4:30 pm PST, Wynn, Level 1, Montrachet 1) AWS Fargate は世界中のミッションクリティカルなワークロードの実行基盤として信頼され、サーバーレスコンテナワークロードの最適化とチューニングに役立つさまざまな機能を提供しています。このチョークトークに参加して、SOCI によるイメージの遅延読み込み、 AWS Compute Optimizer によるコンテナの適切なサイズ設定、代替圧縮メカニズム ZSTD の使用などの新機能の使用方法を聞いてください。 ワークショップ CON201 | Amazon ECS と AWS Fargate で生成系 AI の可能性を解き放とう 11 月 30 日 (木) 08:00 am JST | (Nov 29, 3:00 pm PST, MGM Grand, Level 3, Premier 311) 生成系 AI は、デジタルビジネスのさまざまな側面に影響を与える可能性があります。このワークショップでは、AWS の生成系 AI サービスとサーバーレスコンテナサービスの力を組み合わせて、サンプルアプリケーションをゼロから構築する方法を学びます。このワークショップで学習したアプローチは、例えばアプリケーションログ、ドキュメント、顧客メモなど、さまざまな非構造化データにインテリジェントな検索および検出機能を追加するために使用できます。参加には自身のラップトップを持参する必要があります。 CON202 | AWS Fargate と Amazon EC2: どちらの起動タイプを使用すべきですか? 11 月 28 日 (火) 10:00 am JST | 11 月 30 日 (木) 05:00 am JST | 12 月 1 日 (金) 4:30 am JST | (Nov 27, 5:00 pm PST, MGM – Grand 117 | Nov 29, 12:00 pm PST, Venetian, Level 3, Lido 3006 | Nov 30, 11:30 am, Mandalay Bay, Breakers I) 多くの企業が AWS Fargate を選ぶ理由は、Amazon EC2 インスタンスを管理するための運用上のオーバーヘッドを取り除くことができることや、そのシンプルさと使いやすさにあります。ただし、AWS Fargate への移行がワークロードにどのように影響するかを尋ねるユーザーもいます。このワークショップでは、Amazon EC2 の CPU、メモリリクエスト、制限の設定を AWS Fargate と比較して調べ、ワークロードに適した起動タイプを決定するのに役立ちます。ワークロードが要求されたリソースの外部で動作する場合の動作の違いについて説明します。合成負荷生成を通じて実際のアプリケーションの動作をシミュレートすることで、さらに深く掘り下げることができます。参加には自身のラップトップを持参する必要があります。 CON304 | Amazon ECS と AWS Fargate のサービスディスカバリーオプションについて 11 月 28 日 (火) 07:00 am JST | (Nov 27, 2:00 pm, Wynn, Upper Level, Cristal 1) サービスディスカバリは AWS Fargate 上で、回復力があるスケーラブルなマイクロサービスを構築する上で重要な役割を果たします。Amazon ECS on AWS Fargate には複数のサービスディスカバリのオプションがあり、それぞれに独自の機能とトレードオフがあります。このワークショップでは、利用可能なさまざまなサービスディスカバリのオプションについて詳しく説明します。これらのオプションを比較し、意思決定に必要な情報を提供します。Amazon ECS Service Connect、 AWS Cloud Map 、 Application Load Balancer について、それぞれの利点、制限、ユースケースを検討します。実践的な例とベストプラクティスを通じて、さまざまなサービスディスカバリのオプションが、ダイナミックでコンテナ化された環境の管理をどのように簡素化するかを学びます。参加には自身のラップトップを持参する必要があります。 CON403 | Amazon ECS でコンテナイメージの遅延読み込みを実現する Seekable OCI (SOCI) 11 月 29 日 (水) 07:00 am JST | (Nov 28, 2:00 pm PST, MGM Grand, Level 1, Grand 123) Seekable OCI (SOCI) は、AWS がオープンソースで提供しているテクノロジーです。コンテナイメージのロードを遅延させることでコンテナをより高速に起動できるようにします。このワークショップでは、SOCI を実際に体験します。既存のコンテナイメージの SOCI インデックスを作成する方法と、AWS 上ででインデックス生成を自動化する方法について説明します。次に Amazon ECS on AWS Fargate にワークロードをデプロイする方法を学びます。コンテナイメージを遅延ロードすることで、起動時間がどのように短縮されるかを体験してください。参加には自身のラップトップを持参する必要があります。 開発者向けセッション CON301 | Amazon ECS でコストを最適化したワークロードを構築 11 月 28 日 (火) 07:30 am JST | 11 月 30 日 (木) 03:30 am JST | 12 月 01 日 (金) 06:00 am JST | 12 月 01 日 (金) 08:30 am JST | (Nov 27, 2:30 pm PST, Caesars Forum, Level 1, Alliance 315 | Nov 29, 10:30 am PST , Caesars Forum, Level 1, Alliance 311 | Nov 30, 1:00 pm PST, MGM, 350 | Nov 30, 3:30 pm PST, MGM, 353) コストの最適化はワークロードの設計や改善を行う際の重要な考慮事項です。このセッションでは Amazon ECS での請求をきめ細かく可視化し、適切なサイズのワークロードの実現を目指します。オートスケーリング、AWS Graviton、スポットインスタンスを使用してコストをさらに最適化する方法を探ります。このセッションは Amazon ECS への移行を始めたばかりの企業だけでなく、すでに本番レベルで Amazon ECS ワークロードを利用している企業にも適用できます。これらの概念をワークロードに適用できるようにすることを目的としたハンズオンセッションです。参加には自身のラップトップを持参する必要があります。 CON324 | Amazon ECS ワークロードでのデータ保護とコンプライアンス設計 11 月 28 日 (火) 07:30 am JST | 11 月 29 日 (水) 08:30 am JST | 11 月 30 日 (木) 09:30 am JST | 12 月 2 日 (土) 02:00 am JST | (Nov 27, 2:30 pm PST , MGM Grand, Level 1, Terrace 151 | Nov 28, 3:30 pm PST, Mandalay Bay, Surf A | Nov 29, 4:30 pm PST, Wynn, Level 1, Latour 7 | Dec 1, 9:00 am, Caesars Forum, Level 1, Academy 416) コンテナ化されたワークロードを実行している多くの企業は、保護対象の医療情報 (PHI) データを保護するための HIPAA プライバシー、およびセキュリティルールに関連するものを含む厳格なデータ保護およびコンプライアンス要件を満たしていることを確認する必要があります。このセッションでは Amazon ECS やその他の AWS サービスを使用して、 PHI を含むコンテナアプリケーションを実行する方法に焦点を当てます。Amazon ECS、Amazon ECR、AWS Fargate、 Amazon GuardDuty に関するベストプラクティスを学びましょう。参加には自身のラップトップを持参する必要があります。 直接参加できない場合は、基調講演とリーダーシップセッションのライブストリームに参加できます。 イベントに登録 して、バーチャル参加専用パスを選択できます。ブレイクアウトセッションは、イベント終了後に YouTube チャンネルで視聴できます。 これらのセッションの詳細や、AWS のエキスパートとのディスカッションに興味がある場合は、AWS 担当者にお問い合わせください。 re:Invent 2023でお会いできるのを楽しみにしています！その他の学習リソースについては、 Amazon ECS にアクセスしてください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

このブログは Kumar Kumaraguruparan による “ Learn to build, train, and iterate machine learning models faster with new AWS course ” を翻訳+加筆修正したものです。 機械学習（Machine Learning: ML）が、潜在的な COVID ワクチン候補の数を数万から 26 に減らす上で重要な役割を果たしたことをご存知ですか ( PMC )？ ML によって生産性が向上することで、COVID ワクチンの開発においては多くの人々の命を救いました。 AWS クラウドでMLモデル構築のパフォーマンスを向上 パブリッククラウドにおける非構造化データ分析およびデータ管理市場は、2021年から2025年の間に41.9％の CAGR（年平均成長率）で成長すると予想されています ( IDC )。データは ML モデルを構築・チューニングするために必要です。ML モデル構築作業をクラウドに移行してデータの移動を減らすことで、モデル開発のスピードアップが期待できます。データや分析のワークロードがすでに AWS にある場合や、AWS クラウドサービスを検討している場合は、ML ワークロードを AWS クラウドに統合することでモデル構築のパフォーマンスを向上させることができます。 Amazon SageMaker Studio について Amazon SageMaker Studio は ML 専用の統合開発環境 (IDE) です。SageMaker Studio は、データの準備から、ML モデルのデプロイと監視まで、ML 開発のすべてのステップを実行でき、Web ベースのビジュアルインターフェイスで包括的なツールセットにアクセスできます。 2020 年の Anaconda 社によるデータサイエンスに関する調査 ( Anaconda Survey ) によると、回答者は仕事の時間の 66% がデータの読み込み、クレンジング、可視化に費やされていると答えています。データが指数関数的に増加し続ける中、データをより迅速に変換、分析、可視化するツールがさらに重要になっています。 SageMaker Studio と統合された SageMaker Data Wrangler では、300 種類以上の組み込み関数が利用でき、データ変換時間の短縮と、データに関するインサイトの生成を支援します。SageMaker Studio は、Amazon EMR クラスター上で実行されている Apache Spark と Studio ノートブックの統合による、大規模なデータ処理もサポートしています。また、AWS Glue Interactive Sessions が管理するサーバーレスの Apache Spark ランタイム環境を使用して、Studio ノートブックから、大規模データをインタラクティブに処理することもできます。 SageMaker Studio は、SageMaker Debugger によるモデルのデバッグとプロファイリングに役立つだけでなく、実験やトライアルに関連する詳細を自動的に追跡してグラフ化することで、データサイエンティストの生産性を向上させます。SageMaker Clarify を使用すると、データサイエンティストはデータやモデルのバイアスを特定し、特定の予測の理由（説明可能性）についてのインサイトを得ることができます。 これらの機能を活用するために必要なスキルを身に付けることは、オンプレミスの機械学習から AWS クラウドに移行する企業や、SageMaker を使用してクラウドネイティブソリューションを構築する企業にとって重要です。 3 日間の新クラスルームコースについて 「Amazon SageMaker Studio for Data Scientist」  は上級レベルの 3 日間のコースで、専門の AWS インストラクターと一緒にSageMaker Studio を使用して ML モデルをより迅速に構築、トレーニング、反復する方法を学習します。 トレーニングでは、ML タスクの時間を節約する 5 つの主要スキルを学ぶことができます。 SageMaker Data Wrangler の組み込み変換を使用して特徴量エンジニアリングを行い、SageMaker Feature Store を使用してそれらの特徴量を共有する方法 組み込みアルゴリズム、SageMaker AutoPilot、SageMaker Debugger、自動モデルチューニングを使用してモデルをより速く構築する方法 SageMaker Experiments を使用してモデルトレーニングに関連するさまざまなトライアルのパフォーマンスを比較し、SageMaker モデルレジストリでトラックする方法 SageMaker Clarify を使用してデータとモデル内のバイアスを特定する方法 SageMaker Pipelines を使用してモデル構築ワークフローを自動化する方法 このコースは、特徴量エンジニアリングからモデル構築、トレーニング、チューニング、そしてデプロイ、推論、モニタリングへと続く ML ライフサイクルをたどります。10 個のラボを通して、Amazon SageMaker Studio の 8 つの主要な機能について学びます。 さらに、AWS インストラクターのインタラクティブなセッションでは、SageMaker Studio ユーザーインターフェイス、SageMaker AutoPilot、および SageMaker Model Monitor などについても説明します。最後に、SageMaker Python SDK と SageMaker Studio についての理解度をテストするための 7 つのチャレンジを含んだハンズオンラボが用意されています。各課題の難易度を、ヒントなし、ヒントのみ、または詳細なガイド付きから選択できます。 このコースを最大限に活用するには、学習者に 1 年以上の ML の経験と Amazon SageMaker に関する基礎知識と、AWS の基礎知識があることをお勧めします。AWS Technical Essentials コースを修了することで、AWS の基礎知識の要件を満たすことができます。 ML の経験や Amazon SageMaker に関する基礎知識がない方は、事前に中級レベルの機械学習関連のコースを修了することもお勧めです。 中級レベルの機械学習関連コース The Machine Learning Pipeline on AWS このコースでは、機械学習 (ML) パイプラインを使用して、ビジネス上の問題を解決する方法を学びます。4日間のトレーニングは、機械学習の種類や、モデル・特徴量・アルゴリズムといった機械学習の基本の解説から始まり、問題の定式化、データの前処理、モデルトレーニングなどの機械学習パイプラインの各フェーズで発生するタスクと、タスクを実行するための Amazon SageMaker の機能を学ぶことができます。機械学習入門者や、Amazon SageMaker について詳しく学びたい方にお勧めのトレーニングです。本コースを受講することで、新コースの受講前提である ML の経験や Amazon SageMaker に関する基礎知識の習得が可能です。 Practical Data Science with Amazon SageMaker このコースは、顧客の解約を予測するというユースケースを題材に、Amazon SageMaker を使用したモデル構築、トレーニング、チューニング、およびデプロイの実践方法をハンズオン形式で学習します。コースの期間は1日で、既に機械学習の知識があり、Amazon SageMaker の機能を体験したい方や、機械学習モデルの開発を短時間で体験してみたい方にお勧めです。新コース受講の前提知識である SageMaker の基礎知識の習得にもお勧めです。 MLOps Engineering on AWS このコースは DevOps のプラクティスを機械学習に適用し、モデルの構築、トレーニング、およびデプロイを迅速化・効率化する方法を学習します。コースの期間は3日間です。新コースと比較すると、このコースの目標は MLOps に特化しており、MLOps が必要になる背景やメリットといった観点から、MLOps の組織・プラクティス・ツールに関するベストプラクティスをについて詳しく学ぶことができます。このコースには、オープンソースを含めた、複数の MLOps 自動化ソリューションについての比較も含まれています。 コース開催予定 本ブログの中で紹介している新コース「 Amazon SageMaker Studio for Data Scientists 」は、2024年2月から日本語クラスも提供開始予定です。Amazon SageMaker Studio を活用して、データサイエンスタスクの生産性を向上させる方法に興味がある方は、ぜひご受講を検討いただければと思います。AWS Training & Certification で開催日の検索とお申し込みが可能です ( 今後のコースの開催予定の検索 )。コースの期間は3日間、直近の開催は2024年2月、5 月で下記リンクからお申込みいただけます。お待ちしております。 2024/02/26 – 2024/02/28 2024/05/28 – 2024/05/30 この記事の執筆および翻訳は Technical Instructor の佐中晋が担当しました。