AWS規範ガイダンス用語集 - AWS の規範的ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS規範ガイダンス用語集

AIとMLの用語|移行用語|近代化用語

AIとMLの用語

以下は、によって提供される人工知能(AI)および機械学習(ML)に関連する戦略、ガイド、およびパターンで一般的に使用される用語です。AWS規範的ガイダンス エントリを提案するには、フィードバックの提供用語集の最後にリンクします。

バイナリ分類

バイナリ結果を予測するプロセス (2 つの可能なクラスのうちの 1 つ)。たとえば、ML モデルで「このメールはスパムですか、それともスパムではないのですか」などの問題を予測する必要がある場合があります。または「この商品は本でしょうか、それとも車でしょうか」。

分類

予測を生成するのに役立つ分類プロセス。分類問題の ML モデルは、離散値を予測します。離散値は、常に互いに区別されます。たとえば、モデルがイメージ内に車があるかどうかを評価する必要がある場合があります。

データの前処理

raw データを ML モデルで簡単に解析できる形式に変換します。データの前処理とは、特定の列または行を削除して、欠落、矛盾している、または重複する値に対処することを意味します。

ディープリンク

予測のために複数のディープラーニングモデルを組み合わせること。ディープ・アンサンブルを使用して、より正確な予測を取得したり、予測の不確実性を推定したりできます。

ディープラーニング

人工ニューラルネットワークの複数層を使用して、入力データと対象のターゲット変数の間のマッピングを識別する ML サブフィールド。

探索データ分析 (EDA)

データセットを分析してその主な特性を理解するプロセス。データを収集または集計してから、パターンの検出、異常の検出、および前提条件のチェックのための初期調査を実行します。EDA は、サマリー統計を計算し、データビジュアライゼーションを作成することによって実行されます。

特徴

予測に使用する入力データ。たとえば、製造コンテキストでは、フィーチャーは製造ラインから定期的にキャプチャされるイメージである可能性があります。

機能の重要性

モデルの予測に対する特徴量の重要性。これは通常、Shapley Additive Deskellations (SHAP) や積分勾配など、さまざまな手法で計算できる数値スコアで表されます。詳細については、「」を参照してください。AWS を使用した機械学習モデルの解釈可能性

機能変換

追加のソースによるデータのエンリッチ化、値のスケーリング、単一のデータフィールドからの複数の情報セットの抽出など、ML プロセスのデータを最適化します。これにより、ML モデルはデータの恩恵を受けることができます。たとえば、「2021-05-27 00:15:37」の日付を「2021」、「5月」、「木」、「15」に分解すると、学習アルゴリズムがさまざまなデータコンポーネントに関連する微妙なパターンを学習するのに役立ちます。

解釈

機械学習モデルの特性で、モデルの予測が入力にどのように依存するかを人間が理解できる程度を記述します。詳細については、「」を参照してください。AWS を使用した機械学習モデルの解釈可能性

マルチクラス分類

複数のクラスの予測を生成するのに役立つプロセス (2 つ以上の結果の 1 つを予測します)。たとえば、ML モデルで「この製品は書籍、自動車、電話のいずれですか」という質問があります。または「この顧客にとって最も関心のある商品カテゴリはどれですか」。

退行

数値を予測する ML 手法。たとえば、「この家はどのような値段で売れるでしょうか」という問題を解決します。ML モデルは、線形回帰モデルを使用して、住宅に関する既知の事実 (平方フィートなど) に基づいて家の販売価格を予測できます。

トレーニング

ML モデルに学習するデータを提供するため。トレーニングデータには正しい答えが含まれている必要があります。学習アルゴリズムは、入力データ属性をターゲット (予測したい答え) にマッピングするトレーニングデータ内のパターンを検出します。これらのパターンをキャプチャする ML モデルを出力します。ML モデルを使用して、ターゲットがわからない新しいデータでターゲットを予測できます。

ターゲット変数

教師付き ML で予測しようとしている値。これは、結果変数。たとえば、製造設定では、ターゲット変数が製品の欠陥である可能性があります。

チューニング

ML モデルの精度を向上させるために、トレーニングプロセスの側面を変更する。たとえば、ML モデルをトレーニングします。そのためには、ラベリングセットを生成し、ラベルを追加します。これらのステップを、異なる設定で複数回繰り返して、モデルを最適化します。

不確実性

予測MLモデルの信頼性を損なう可能性がある、不正確な、不完全、または未知の情報を指す概念。不確定性には 2 種類あります。認識論的不確実性が限られた、不完全なデータによって引き起こされる。一方、弁論的不確実性は、データに固有のノイズとランダム性によって引き起こされます。詳細については、「」を参照してください。ディープラーニングシステムにおける不確実性の定量化ガイド.

移行用語

以下は、によって提供される移行関連の戦略、ガイド、およびパターンで一般的に使用される用語です。AWS規範的ガイダンス エントリを提案するには、フィードバックの提供用語集の最後にリンクします。

7 ルピー

アプリケーションをクラウドに移行するための 7 つの一般的な移行戦略。これらの戦略は、ガートナーが2011年に特定した5ルピーに基づいて構築され、以下で構成されています。

  • リファクタリング/再構築 — クラウドネイティブ機能を最大限に活用して、俊敏性、パフォーマンス、スケーラビリティを向上させ、アプリケーションを移動し、アーキテクチャを変更します。これには、通常、オペレーティングシステムとデータベースの移植が含まれます。例: オンプレミスの Oracle データベースを Amazon Aurora PostgreSQL 互換エディションに移行します。

  • 再プラットフォーム (リフトと形状変更) — アプリケーションをクラウドに移行し、クラウド機能を活用するための最適化レベルを導入します。例: オンプレミスの Oracle データベースをの Oracle の Amazon Relational Database Service (Amazon RDS) に移行します。AWSCloud

  • 買い戻し (ドロップアンドショップ) — 通常、従来のライセンスから SaaS モデルに移行して、別の製品に切り替えます。例: 顧客関係管理 (CRM) システムを Salesforce.com に移行します。

  • 再ホスト (リフトとシフト) — クラウド機能を利用するための変更を加えずに、アプリケーションをクラウドに移行します。例: オンプレミスの Oracle データベースを、の EC2 インスタンスの Oracle に移行します。AWSCloud

  • 再配置(ハイパーバイザレベルのリフトとシフト)— 新しいハードウェアの購入、アプリケーションの書き換え、既存のオペレーションの変更を行うことなく、インフラストラクチャをクラウドに移行できます。この移行シナリオは VMware Cloud on に固有のものです。AWS。これは、オンプレミス環境と、およびオンプレミス環境間の仮想マシン (VM) の互換性とワークロードの移植性をサポートします。AWS。インフラストラクチャを VMware Cloud に移行するときに、オンプレミスのデータセンターから VMware Cloud Foundation テクノロジーを使用できます。AWS。例: Oracle データベースをホストしているハイパーバイザを VMware Cloud on に再配置します。AWS。

  • 保持 (再訪) — アプリケーションをソース環境に保持します。これには、主要なリファクタリングを必要とするアプリケーションや、その作業を後日まで延期したいアプリケーション、およびそれらを移行するためのビジネス上の正当性がないため、保持するレガシーアプリケーションなどがあります。

  • リタイア — ソース環境で不要になったアプリケーションを停止または削除します。

アプリケーションポートフォリオ

組織が使用する各アプリケーションに関する詳細情報の集まり。アプリケーションの構築と維持にかかるコスト、およびそのビジネス価値を含む。この情報は、ポートフォリオの検出と分析プロセスまた、移行、モダナイズ、最適化するアプリケーションを特定し、優先順位を付けるのに役立ちます。

人工知能オペレーション (AioP)

機械学習技術を使用して運用上の問題を解決し、運用上のインシデントと人間の介入を減らし、サービス品質を向上させるプロセス。での AiOps の使用方法の詳細については、「」を参照してください。AWS移行戦略については、を参照してください。オペレーション統合ガイド

AWSクラウド導入フレームワーク (AWSCAF)

のガイドラインとベストプラクティスのフレームワークAWS組織がクラウドに正常に移行するための効率的で効果的な計画を立てるのを支援します。AWSCAFは、ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、運用のパースペクティブと呼ばれる6つの重点分野にガイダンスを編成しています。ビジネス、人材、ガバナンスの観点では、ビジネススキルとプロセスに重点を置き、プラットフォーム、セキュリティ、オペレーションの視点は技術的なスキルとプロセスに焦点を当てています。たとえば、ピープルパースペクティブは、人事(HR)、人材派遣機能、および人材管理を扱う利害関係者を対象としています。この観点から、AWSCAF は、クラウドの導入を成功させるための組織の準備を支援するために、人材開発、トレーニング、コミュニケーションに関するガイダンスを提供します。詳細については、AWS クラウド導入フレームワーク (AWS CAF)と「AWS Cloud Adoption Framework の概要」を参照してください。

AWSlanding zone

landing zone は、優れたアーキテクチャ設計の、複数アカウントです。AWSスケーラブルで安全な環境。これは、組織がセキュリティおよびインフラストラクチャ環境に自信を持ってワークロードとアプリケーションを迅速に起動してデプロイできる出発点です。ランディングゾーンの詳細については、「」を参照してください。安全でスケーラブルなマルチアカウントのセットアップAWS環境

AWSワークロード資格フレームワーク (AWSWQF)

データベース移行ワークロードを評価し、移行戦略を推奨し、作業の見積もりを提供するツール。AWSWQF はAWS Schema Conversion Tool(AWS SCT). データベーススキーマとコードオブジェクト、アプリケーションコード、依存関係、およびパフォーマンス特性を分析し、評価レポートを提供します。

ビジネス継続性計画 (BCP)

大規模な移行など、中断を伴うイベントが運用に与える潜在的な影響に対処し、業務を迅速に再開できるようにする計画。

Cloud Center of Excellence (CCoE)

クラウドのベストプラクティスの開発、リソースの移動、移行のタイムラインの確立、大規模な変革を通じて組織をリードするなど、組織全体のクラウド導入の取り組みを推進する学際的なチームです。詳細については、「」を参照してください。ccoE 投稿でAWSクラウドエンタープライズ戦略ブログ。

クラウド導入の段階

組織は、通常、移行時に実行される 4 つのフェーズAWSCloud:

  • Project — 概念実証と学習を目的として、クラウド関連のプロジェクトをいくつか実行する

  • 財団 — クラウドの導入を拡大するための基礎的な投資(landing zone 作成、CCoE の定義、運用モデルの確立など)

  • 移行 — 個々のアプリケーションの移行

  • 再発明 — 製品とサービスの最適化、クラウドでのイノベーション

これらのステージは、Stephen Orbanがブログ記事で定義したものです。クラウドファーストへの旅と導入の段階でAWSクラウドエンタープライズ戦略ブログ。がどのように関連しているのかについては、「」を参照してください。AWS移行戦略については、を参照してください。移行準備ガイド

構成管理データベース (CMDB)

企業のハードウェアおよびソフトウェア製品、構成、相互依存関係に関する情報を含むデータベース。通常、CMDB のデータは、移行のポートフォリオの検出と分析の段階で使用します。

叙事詩

アジャイル方法論では、作業の整理と優先順位付けに役立つ機能カテゴリ。エピックは、要件および実装タスクの詳細な説明を提供します。たとえば、AWSCAF セキュリティエピックには、ID とアクセス管理、探偵制御、インフラストラクチャセキュリティ、データ保護、インシデント対応が含まれます。の叙事詩の詳細については、「」を参照してください。AWS移行戦略については、を参照してください。プログラム実装ガイド

異機種混在データベースの移行

別のデータベースエンジンを使用するターゲットデータベースへのソースデータベースの移行 (たとえば、Oracle から Amazon Aurora)。異機種間移行は通常、再設計作業の一部であり、スキーマの変換は複雑な作業になる可能性があります。AWS提供するAWS SCTこれは、スキーマの変換に役立ちます。

同種のデータベースの移行

ソースデータベースを、同じデータベースエンジンを共有するターゲットデータベース (Microsoft SQL Server から Amazon RDS for SQL Server など) に移行する。同種移行は、通常、リホストまたは再プラットフォーム化の作業の一部です。ネイティブデータベースユーティリティを使用して、スキーマを移行できます。

アイドル状態のアプリケーション

90 日間の平均的な CPU およびメモリ使用率が 5 ~ 20% のアプリケーション。移行プロジェクトでは、これらのアプリケーションを廃止するか、オンプレミスに保持するのが一般的です。

IT情報ライブラリ (ITIL)

IT サービスを提供し、これらのサービスをビジネス要件に合わせるための一連のベストプラクティス。ITIL は ITSM の基盤を提供します。

ITサービス管理 (ITSM)

組織の IT サービスの設計、実装、管理、およびサポートに関連する活動。クラウドオペレーションを ITSM ツールに統合する方法の詳細については、「」を参照してください。オペレーション統合ガイド

サイズの大きな移行

300 台以上のサーバの移行。

Migration Acceleration Program (MAP)

AnAWS組織がクラウドへの移行のための強力な運用基盤を構築し、移行の初期コストを相殺するのに役立つコンサルティングサポート、トレーニング、サービスを提供するプログラムです。MAP には、組織的な方法でレガシー移行を実行するための移行方法論と、一般的な移行シナリオを自動化および高速化する一連のツールが含まれています。

移行ポートフォリオ評価 (MPA)

に移行するためのビジネスケースを検証するための情報を提供するオンラインツールAWSCloud MPAは、詳細なポートフォリオ評価(サーバの適切なサイジング、価格設定、TCO比較、移行コスト分析)および移行計画(アプリケーションデータの分析とデータ収集、アプリケーションのグループ化、移行の優先順位付け、およびウェーブプランニング)を提供します。MPA ツール (ログインが必要) は、すべての人に無料で利用できる AWS コンサルタントと APN パートナーコンサルタントです。

移行準備評価 (MRA)

組織のクラウド対応状況に関するインサイトを獲得し、長所と短所を特定し、特定されたギャップを埋めるためのアクションプランを構築するプロセスAWSカフェ。詳細については、「」を参照してください。移行準備ガイド。MRAは、最初のフェーズですAWS 移行戦略

大規模な移行

アプリケーションポートフォリオの大部分をWavesでクラウドに移行し、各ウェーブでより多くのアプリケーションを高速に移動させるプロセス。このフェーズでは、以前のフェーズから学んだベストプラクティスと教訓を使用して、移行ファクトリチーム、ツール、プロセスのうち、自動化とアジャイル・デリバリーによってワークロードの移行を合理化します。これは、第3段階のAWS移行戦略

移行ファクトリ

自動化されたアジャイルなアプローチにより、ワークロードの移行を合理化する部門横断的なチーム。移行ファクトリチームには、通常、オペレーション、ビジネスアナリストおよびオーナー、移行エンジニア、開発者、DevOpsスプリントで働くプロフェッショナル。エンタープライズ・アプリケーション・ポートフォリオの20~ 50% は、工場のアプローチによって最適化できる繰り返しパターンで構成されています。詳細については、「」を参照してください。移行ファクトリの議論CloudEndure移行ファクトリのガイドこのコンテンツセットです。

移行メタデータ

移行を完了するために必要なアプリケーションおよびサーバーに関する情報。移行パターンごとに、異なる移行メタデータのセットが必要です。移行メタデータの例としては、ターゲットサブネット、セキュリティグループ、AWSアカウント.

移行パターン

移行戦略、移行先、および使用する移行アプリケーションまたはサービスを詳述する、反復可能な移行タスク。例: で Amazon EC2 への移行を再ホストするAWSアプリケーション移行サービス。

移行戦略

ワークロードをAWSCloud 詳細については、「」を参照してください。7 ルピーこの用語集に記入し、組織を動員して大規模な移行を加速する

運用レベル契約 (OLA)

サービスレベルアグリーメント(SLA)をサポートするために、どの機能ITグループが互いに提供することを約束するかを明確にする契約。

オペレーション統合 (OI)

クラウドでのオペレーションをモダナイズするプロセス。これには、準備計画、自動化、統合が含まれます。詳細については、「」を参照してください。オペレーション統合ガイド

組織変更管理 (OCM)

人、文化、リーダーシップの観点から、主要な破壊的なビジネス変革を管理するためのフレームワーク。OCMは、変化の採用を加速し、移行問題に対処し、文化や組織の変化を推進することで、組織が新しいシステムと戦略の準備と移行を支援します。左AWS移行戦略、このフレームワークは人の高速化クラウド導入プロジェクトに必要な変更のスピードが原因です。詳細については、「」を参照してください。OCMガイド

プレイブック

クラウドでのコアオペレーション機能の提供など、移行に関連する作業を取り込む、事前定義された一連のステップ。プレイブックは、スクリプト、自動ランブック、またはモダナイズド環境の運用に必要なプロセスや手順の概要の形式をとることができます。

ポートフォリオ評価

移行を計画するために、アプリケーションポートフォリオの検出、分析、優先順位付けを行うプロセス。詳細については、「」を参照してください。移行の準備状況の評価

責任、説明責任、コンサルティング、情報提供 (RACI) マトリックス

プロジェクト内のロールと責任を定義して割り当てるマトリックス。たとえば、RACI を作成して、セキュリティコントロールの所有権を定義したり、移行プロジェクト内の特定のタスクのロールと責任を特定したりできます。

ランブック

特定のタスクを実行するために必要な手動または自動の手順セット。これらは、通常、エラー率の高い反復操作や手順を合理化するために構築されています。

サービスレベルアグリーメント (SLA)

サービスの稼働時間やパフォーマンスなど、ITチームが顧客に提供することを約束するものを明確にする契約。

タスクリスト

Runbook の進行状況を追跡するために使用されるツール。タスクリストには、Runbook の概要と完了する一般的なタスクのリストが含まれています。一般的なタスクごとに、推定所要時間、所有者、進捗状況が含まれます。

ワークストリーム

特定のタスクセットを担当する移行プロジェクト内の機能グループ。各ワークストリームは独立していますが、プロジェクト内の他のワークストリームをサポートしています。たとえば、ポートフォリオワークストリームは、アプリケーションの優先順位付け、ウェーブプランニング、および移行メタデータの収集を担当します。ポートフォリオワークストリームは、これらの資産を移行ワークストリームに配信し、サーバーとアプリケーションを移行します。

ゾンビアプリケーション

平均 CPU およびメモリ使用率が 5% 未満のアプリケーション。移行プロジェクトでは、これらのアプリケーションを廃止するのが一般的です。

近代化用語

以下に示すのは、近代化に関連する戦略、ガイド、およびパターンで一般的に使用される用語です。AWS規範的ガイダンス エントリを提案するには、フィードバックの提供用語集の最後にリンクします。

ビジネス機能

価値を生み出すために事業を行うこと(営業、カスタマーサービス、マーケティングなど)。マイクロサービスのアーキテクチャと開発の決定は、ビジネス能力によって推進できます。詳細については、「」を参照してください。ビジネス機能を中心に組織化の セクションコンテナ化されたマイクロサービスの実行AWSホワイトペーパー

ドメイン駆動型設計

各コンポーネントが提供する進化するドメイン、つまりコアビジネス目標にコンポーネントを接続して、複雑なソフトウェアシステムを開発するアプローチ。この概念は、エリック・エヴァンスの著書で紹介され、ドメイン駆動設計: ソフトウェアの中心における複雑さへの取り組み(ボストン:Addison-Wesley Professional、2003)。ストレンジラー fig パターンでドメイン駆動設計を使用する方法については、「」を参照してください。コンテナと Amazon API Gateway を使用して、レガシー Microsoft ASP.NET (ASMX) ウェブサービスを段階的にモダナイズ

マイクロサービスに

明確に定義された API を介して通信し、通常は小規模な自己完結型のチームが所有する、小規模で独立したサービスです。たとえば、保険システムには、販売やマーケティングなどのビジネス機能、または購買、請求、分析などのサブドメインにマップするマイクロサービスが含まれる場合があります。マイクロサービスのメリットには、俊敏性、柔軟なスケーリング、容易なデプロイ、再利用可能なコード、復元力などがあります。詳細については、「」を参照してください。を使用してマイクロサービスを統合するAWSサーバーレスサービス

マイクロサービスアーキテクチャ

各アプリケーションプロセスをマイクロサービスとして実行する独立したコンポーネントを使用してアプリケーションを構築するアプローチ。これらのマイクロサービスは、軽量 API を使用して、明確に定義されたインターフェイスを介して通信します。このアーキテクチャの各マイクロサービスは、アプリケーションの特定の機能に対する需要を満たすように更新、デプロイ、およびスケーリングできます。詳細については、「」を参照してください。でのマイクロサービスの実装AWS

近代化

古い(レガシーまたはモノリシック)アプリケーションとそのインフラストラクチャをクラウド内のアジャイルで弾力性のある高可用性システムに変換して、コストを削減し、効率を高め、イノベーションを活用します。詳細については、「」を参照してください。アプリケーションのモダナイズ戦略AWSCloud

近代化の準備評価

組織のアプリケーションのモダナイゼーションの準備状況を判断し、メリット、リスク、依存関係を特定し、組織がこれらのアプリケーションの将来の状態をどの程度適切にサポートできるかを決定するのに役立つ評価。評価の結果は、ターゲットアーキテクチャの設計図、近代化プロセスの開発段階とマイルストーンを詳述したロードマップ、特定されたギャップに対処するためのアクションプランです。詳細については、「」を参照してください。アプリケーションのモダナイゼーションの準備状況の評価AWSCloud

モノリシックアプリケーション (モノリス)

緊密に結合されたプロセスを持つ単一のサービスとして実行されるアプリケーション。モノリシックアプリケーションにはいくつかの欠点があります。1 つのアプリケーション機能の需要が急増する場合は、アーキテクチャ全体をスケーリングする必要があります。モノリシックアプリケーションの機能を追加または改善することは、コードベースが大きくなると複雑になります。これらの問題に対処するには、マイクロサービスアーキテクチャを使用できます。詳細については、「」を参照してください。モノリスをマイクロサービスに分解

ポリグロット永続性

データアクセスパターンやその他の要件に基づいて、マイクロサービスのデータストレージテクノロジーを個別に選択する。マイクロサービスが同じデータストレージテクノロジーを使用している場合、実装上の問題が発生したり、パフォーマンスが低下する可能性があります。マイクロサービスは、要件に最も適合したデータストアを使用すると、より簡単に実装でき、パフォーマンスとスケーラビリティが向上します。詳細については、「」を参照してください。マイクロサービスでのデータ永続性の有効化

split-and-seed モデル

近代化プロジェクトのスケーリングと加速のためのパターン。新機能と製品リリースが定義されると、コアチームは分割して新しい製品チームを作成します。これにより、組織の能力とサービスの拡張、開発者の生産性の向上、迅速なイノベーションのサポートに役立ちます。詳細については、「」を参照してください。アプリケーションをモダナイズするための段階的アプローチAWSCloud

絞め師イチジクのパターン

レガシーシステムが廃止されるまで、システム機能を段階的に書き換えて置き換えることにより、モノリシックシステムをモダナイズするアプローチ。このパターンは、確立された木に成長し、最終的にその宿主を克服して置き換えるイチジクのブドウの類推を使用します。パターンはマーティン・ファウラーによる導入モノリシックシステムを書き換えるときのリスクを管理する方法として。このパターンの適用方法の例については、「」を参照してください。コンテナと Amazon API Gateway を使用して、レガシー Microsoft ASP.NET (ASMX) ウェブサービスを段階的にモダナイズ

2ピザチーム

小さなDevOps2つのピザで食べられるチーム。2ピザチームサイズにより、ソフトウェア開発におけるコラボレーションに最適な機会が確保されます。詳細については、「」を参照してください。2ピザチームの セクションについてDevOpsオンAWSホワイトペーパー