クラウドストレージアーキテクチャフレームワークを設計するにはどうすればよいでしょうか?

新興インターネットビジネスの急増とビジネスデータの急速な増加により、クラウドストレージテクノロジーが誕生しました。この記事では、クラウドストレージの一般的なフレームワーク、ハードウェアアーキテクチャ、およびその基本原理の 3 つの技術的側面の違いを深く分析し、クラウドストレージアーキテクチャフレームワークの設計の理論的基礎を提供します。細分化された業界の差別化されたニーズとそれらのビジネスアプリケーションシナリオを組み合わせて、最終的に企業のニーズを満たす全体的なクラウドストレージアーキテクチャを決定し、アーキテクチャ設計の評価とテクノロジの選択のプロセスにおけるいくつかの実践的な経験を詳細に紹介します。

[著者] Chen Pingchun は現在保険業界で働いており、システム、ストレージ、データバックアップなどの運用および保守業務で長年の経験を持っています。

1. 概要

新興インターネットビジネスの急増とビジネスデータの急速な増加により、エンタープライズデータセンターのストレージシステムは新たな課題に直面しています。ビッグデータやクラウドコンピューティングなどの新しいテクノロジーアプリケーションにより、新しいストレージアプリケーションシナリオが生まれています。膨大なデータストレージが従来のストレージアーキテクチャに影響を与え、パフォーマンスと容量がボトルネックになっています。ストレージシステムの拡張と新規構築のサイクルが長く、ビジネスの俊敏性要件を満たすことができません。

クラウドストレージ技術が誕生しました。その俊敏性、柔軟なリソース展開、オンデマンドアクセス特性は、データセンター内の膨大なデータのストレージニーズや新興ビジネスの急速な立ち上げに十分対応します。

2. クラウドストレージ技術の分析

名前が示すように、クラウドストレージはクラウドコンピューティングに基づいて派生および開発されます。多数の異機種ストレージデバイスがネットワークを介して接続され、統合されたストレージリソースプールを形成します。集中型ストレージ技術をベースとし、分散ストレージ、マルチテナント共有、ソフトウェア定義ストレージなどの複数のクラウドストレージ技術を統合します。

新しいテクノロジーの応用には2つの側面があります。クラウドストレージアーキテクチャフレームワークを設計および構築する前に、クラウドストレージテクノロジーを詳細に理解して分析し、独自のニーズに基づいて適切な計画を立てる必要があります。次の記事では、クラウドストレージの一般的なフレームワーク、ストレージハードウェアアーキテクチャ、分散基盤ストレージテクノロジーの 3 つの側面について説明します。

2.1 クラウドストレージの一般的なフレームワーク

従来のストレージと比較すると、クラウドストレージシステムは階層型アーキテクチャです。その一般的なフレームワークは図 1 に示されており、クラウドストレージサービスとクラウドストレージリソースプールの 2 つのタイプに分かれています。クラウドストレージリソースプールは、クラウドストレージの中核部分です。

図1. クラウドストレージの一般的なフレームワーク

クラウドストレージリソースプールは、さらにデータストレージ層、ストレージ抽象化層、ストレージインターフェイス層に分けられます。データストレージ層はクラウドストレージの基盤です。さまざまな種類のハードウェアデバイスで構成され、さまざまな IO パフォーマンスを備えたストレージリソースを提供します。ストレージ抽象化レイヤーは、さまざまな種類のストレージデバイスの論理的な仮想化管理を実装し、上位層アプリケーションにさまざまなストレージリソースの抽象化を提供し、ストレージリソースの柔軟な割り当てを実現します。ストレージインターフェイスレイヤーは、ストレージシステムと外部アプリケーション間のデータ転送を実現するために、さまざまな種類のストレージインターフェイスを提供します。

クラウドストレージサービスは、ユーザーに統合されたプロトコルとプログラミングインターフェイス、クラウドデータディスク、オブジェクトストレージサービスを提供し、クラウドストレージリソースのスケジュール設定と制御のエントリポイントとなります。承認されたユーザーは、パブリックアプリケーションインターフェイスを通じてクラウドストレージにアクセスできます。

2.2 クラウドストレージハードウェアアーキテクチャ

データストレージ層では、差別化されたニーズ、業界セグメント、さまざまなアプリケーションシナリオに基づいて、さまざまなアーキテクチャのデータストレージを展開できます。これは、ストレージハードウェアの選択においても重要な要素です。一般的に、ストレージアーキテクチャは集中型と分散型の 2 種類に分けられます。分散ストレージは、コンピューティングとストレージが分離されているかどうかに基づいて、独立したデプロイメントとハイパーコンバージドアーキテクチャにさらに分類できます。次の記事では、これら 3 種類のストレージアーキテクチャを評価します。

2.2.1 集中ストレージ

集中型ストレージの代表的なものとしては、専用のハードウェアとストレージコントローラーを使用する従来の SAN ストレージや NAS ストレージがあります。そのアーキテクチャを図 2 に示します。ストレージコントローラは、RAID 機能と大容量キャッシュを含む、デュアルコントロールまたはマルチコントローラ相互接続アーキテクチャを採用しています。コントローラのバックエンドは、複数の RAID グループを含むディスクキャビネットに接続されています。各 RAID グループには複数のディスクが含まれており、集中型のディスクアレイを形成します。

図2. 集中型ストレージハードウェアアーキテクチャの概略図

集中型ストレージは一般にブロックストレージまたはファイルストレージインターフェイスサービスを提供しますが、その利点は次のようにまとめられます。

パフォーマンス: IO シャーディングの粒度が小さく、データ IO 転送パスが短いため、レイテンシが低くなり、IOPS が高くなります。

高い信頼性: 独自のハードウェアとストレージコントローラーは信頼性が高く、RAID やハードウェア冗長性などのテクノロジも比較的成熟しています。

強力なデータ一貫性: コントローラーとディスク間の集中型相互接続アーキテクチャにより、可能な限り強力なデータ一貫性が保証されます。

もちろん、従来の集中型ストレージにも欠点があり、そのため、次に示すように分散アーキテクチャが登場しました。

スケーラビリティが低い: 集中型ストレージではディスクキャビネットを無制限に拡張することはできず、ストレージコントローラの拡張機能によって制限されます。

コストの上昇: 集中型ストレージの信頼性の高い専用ハードウェアにより、機器の調達および保守コストも高くなります。

2.2.2 分散ストレージ - 独立したデプロイメントアーキテクチャ

分散ストレージは、スケーラブルなシステム構造を使用して、ネットワークを介して複数の独立したストレージノードにデータを保存します。そのアーキテクチャを図 3 に示します。分散ストレージに依存しないデプロイメントアーキテクチャは、複数の専用ストレージノードで構成され、外部にさまざまなストレージサービスを提供します。

図3. 分散ストレージに依存しない展開アーキテクチャ図

分散ストレージは、従来の専用ハードウェアに依存しなくなりました。そのほとんどは汎用サーバー上に展開され、コアストレージロジックはソフトウェア定義方式で実装されています。その利点は次のとおりです。

柔軟な反復: ハードウェアの反復と比較して、ソフトウェアバージョンの反復サイクルはより高速で柔軟です。

低いハードウェアコスト: 独自のハードウェアへの依存を排除し、ハードウェアコストを削減します。

拡張が容易: 分散アーキテクチャは水平方向に拡張しやすく、パフォーマンス容量を直線的に拡張できます。

分散ストレージの欠点は次のとおりです。

複雑性が高い: 集中型のモノリシックアーキテクチャと比較すると、分散型の運用と保守はより複雑です。

安定性が低い: 一部の製品の技術が十分に成熟しておらず、ハードウェア障害やシステム異常が発生した場合にストレージのパフォーマンスが影響を受けやすくなります。

2.2.3 分散ストレージ - ハイパーコンバージドアーキテクチャ

ハイパーコンバージドアーキテクチャは、コンピューティング、ネットワーク、ストレージを含む全体的なアーキテクチャソリューションであり、そのストレージ自体も分散ストレージです。ハイパーコンバージェンス形式では、コンピューティングとストレージは、汎用サーバー上で実行される同じソフトウェアスタックです。そのアーキテクチャを図 4 に示します。ほとんどのハイパーコンバージェンス製品は、ノード上にコントローラー仮想マシン (CVM) を展開します。 CVM はストレージサービス機能を引き継ぎますが、通常の仮想マシンはデータストレージにアクセスするために CVM と通信する必要があります。

図4. 分散ストレージハイパーコンバージェンスアーキテクチャ図

ハイパーコンバージェンスは、コンピューティング層とストレージ層を適切に結合できる設計コンセプトになる傾向があります。分散ストレージの利点に加えて、次のような利点もあります。

運用と保守の複雑さを軽減: アーキテクチャの設計、展開、日常の運用と保守の管理を簡素化することで、単一のベンダーがすべてのソフトウェアとハードウェアのサポートを提供できます。

分散ストレージの独立展開アーキテクチャの利点は、リソースを自由に割り当てることができ、コンピューティング層とストレージ層を独立して展開および拡張できることです。この観点から見ると、ハイパーコンバージェンスの欠点は次のとおりです。

新たなリソースの孤立: 外部とリソースを共有できないため、リソースの活用と統合管理に問題が生じます。

パフォーマンスの問題: コンピューティングとストレージは、サーバーのハードウェアリソースとネットワーク帯域幅をめぐって競合し、パフォーマンスの問題がより顕著になります。

不十分な水平スケーラビリティ: パフォーマンスリスクは、間接的に大規模に展開できないという問題にもつながります。

システム内部の複雑さ: システムアーキテクチャの簡素化により、内部の複雑さが増します。

2.3 分散基盤ストレージ技術

集中型ストレージと比較すると、分散ストレージはより複雑ですが、大規模なクラウド展開シナリオに適しています。その根底にある原理を深く理解する必要があります。分散ストレージには、独立した展開とハイパーコンバージェンスの間でハードウェアアーキテクチャの違いがあります。論理的な観点から見ると、独立した展開であろうとハイパーコンバージェンスアーキテクチャであろうと、分散ファイルシステム (DFS) と分散キー値 (kv) ストレージという 2 つのストレージテクノロジに主に分けられます。

2.3.1 分散ファイルシステム

クラウドストレージテクノロジーの複雑さは、データ IO と基礎となるデータストレージのマッピングと実装の詳細を隠すストレージ仮想化テクノロジーにもあります。図 5 に示すように、分散ファイルシステム (DFS) は、ファイルディレクトリ構造の特性を持つ仮想ファイルシステムです。 DFS によって提供されるストレージユニットはファイルで構成されます。これらのファイルは論理的に分割され、マルチデータコピー分散アルゴリズムに従って異なるデータノードに分散されます。

図5. DFSベースのクラウドストレージの基本原理の概略図

DFS ベースのクラウドストレージには明確なロジックがあり、GFS、HDFS、その他の一般的なアプリケーションなど、幅広いアプリケーションに対応しています。一部のハイパーコンバージド基盤ストレージも DFS に基づいて実装されていますが、明らかな欠陥もあります。

スケーラビリティの制限: ディレクトリ構造に基づくファイルシステムは、DFS の大規模な拡張のボトルネックになります。

パフォーマンス: ファイルディレクトリ情報をメモリにキャッシュしてデータの検索速度を上げることができますが、ファイル数が一定のレベルに達し、ハードウェアが要件を満たせなくなると、パフォーマンスが急激に低下します。

2.3.2 分散キーバリューストレージ

分散ファイルシステムのファイルディレクトリ管理は、大きなファイルを小さなファイルに分割し、分割統治して、それらをマージして処理するというマップリデュースの設計概念に従います。そのアーキテクチャでは、調整のためにメタデータ管理ノードが必要であり、これは本質的には一種の集中化です。分散キー値 (kv) ストレージは、マスターノード自体のボトルネックを解決する分散型アーキテクチャです。建築設計コンセプトはバランスのとれたデザインです。すべてのノードのステータスは同等であり、データレイアウトアルゴリズムを通じてさまざまなノードに均等に分散されます。一貫性のあるハッシュアルゴリズムと仮想ノードは一般的な方法です。データを直線的に分散する単純なハッシュとは異なり、コンシステントハッシュアルゴリズムはデータを端から端まで接続し、ハッシュ値空間全体を仮想リングに編成します。

Ceph は典型的な分散型キー値ベースのストレージシステムです。オブジェクトデータの分散には、一貫性ハッシュアルゴリズムに基づいて設計され、複数のコピーや障害ドメインの分離などの制約を十分に考慮したクラッシュアルゴリズムが採用されています。その実装原理を図6に示します。

図6. 分散KVに基づくクラウドストレージの基本原理の概略図

DFS ベースのクラウドストレージと比較すると、分散 KV ベースのクラウドストレージはより優れたスケーラビリティをサポートできますが、次のような欠点もあります。

複雑性が高い: 分散 KV ベースのクラウドストレージでは、ストレージ抽象化の別のレイヤーが追加され、システム設計と運用および保守の複雑さが非常に高くなります。

パフォーマンス: 書き込みレイテンシが増加し、複数のデータコピーを書き込むレイテンシが高くなります。

3. クラウドストレージアーキテクチャフレームワークの設計

3.1 全体的な設計原則と方法

クラウドストレージの全体的な設計は、次の 3 つの原則に従う必要があります。

適切性の原則: 企業の実際のビジネスアプリケーションを考慮し、コスト、利益、リスクのバランスに焦点を当てて、特定の業界とアプリケーションシナリオに適応する必要があります。

シンプルさの原則: クラウドストレージアーキテクチャフレームワーク自体は非常に複雑です。アーキテクチャの設計と実際の実装の際には、段階的な進歩にもっと注意を払い、複雑なものを単純化する必要があります。

先見の原則: 業界の主流のクラウドストレージ技術を採用し、技術の進歩を維持し、アーキテクチャのスケーラビリティを考慮する必要があります。

クラウドストレージの分析と設計には、次の 2 つの考え方が含まれます。

1) トップダウン

トップダウンアプローチは、クラウドコンピューティングの全体的なアーキテクチャから始まり、徐々に改良して、クラウドストレージとそのコンポーネントの一般的なフレームワークを分析および設計します。この設計および分析方法では、問題領域と将来の業界のアプリケーションシナリオを明確に理解するだけでなく、ソリューション領域を制御する能力と、クラウドストレージテクノロジの開発とアプリケーションに対する深い理解も必要です。

2) ボトムアップ

ボトムアップアプローチはその逆です。解決すべき実際の問題に基づいてクラウドストレージ製品のテクノロジを選択し、具体的なものから抽象的なものまで、クラウドストレージアーキテクチャフレームワークを段階的に構築します。

クラウドストレージアーキテクチャフレームワークの設計に使用する方法は、企業の実際の状況に基づいて決定する必要があります。トップダウン方式では、より高度な技術的制御とより多くのプロジェクト予算が必要となり、実装前に慎重な計画と十分なテストが必要になります。ボトムアップ方式は、迅速なアプリケーション実装を追求しますが、技術的なアプリケーションの一貫性に注意を払い、アーキテクチャフレームワークの最終目標を考慮する必要があります。

当社の実際の状況を踏まえると、ボトムアップアプローチを採用し、さまざまなビジネスアプリケーションシナリオに応じて適切なクラウドストレージソリューションを評価および実装し、試行錯誤のコストを削減し、継続的な実践の過程でクラウドストレージアーキテクチャフレームワークの進化を促進することがより適切です。

3.2 需要分析

3.2.1 アプリケーションシナリオ分析

多くの場合、業界やビジネスシナリオによって、クラウドストレージのアプリケーションシナリオも異なります。伝統的な産業とインターネット産業の間にも明らかな違いがあります。

コアビジネスアプリケーションシナリオ: 従来の業界では、コアビジネスロジックは頻繁に変更されず、コアシステムのビジネス量の増加は定期的かつ予測可能であり、システムアーキテクチャは安定しています。しかし、インターネット業界では、ビジネスシステムはアジャイルな反復を追求し、ビジネス量は大きく変動し、システムアーキテクチャは単純なものから複雑なものへと変化し、弾力的なスケーリングが求められます。

インターネットビジネスの応用シナリオ：伝統的な産業にとって、インターネットは新たなビジネス拡大チャネルであり、ビジネス変革の方向であり、徐々に試行して開放される必要があります。

非構造化データのシナリオ: 非構造化データのシナリオも大きく異なります。シナリオによっては、非構造化データは主にシステムによって生成または収集された一時的なデータです。一度書き込まれ、複数回読み取られるため、個人ネットワークディスクのシナリオなど、安定した IO パフォーマンスが必要です。その他のシナリオでは、非構造化データは長期保存が必要であり、一度書き込まれるとめったに読み取られず、銀行業務と保険業務の二重記録シナリオのように徐々にコールドデータになります。

データ災害復旧とセキュリティ: 従来の業界でもインターネット業界でも、事業継続のニーズを考慮し、データ災害復旧システムと機密データ保護計画を確立する必要があります。金融業界には、より厳格な国内法や規制、金融規制当局からの要件があります。ビジネスシステムの RTO および RPO 要件はより具体的であり、重要かつ機密性の高いデータは安全かつ制御可能である必要があります。一般的に、クラウドストレージの展開モデルは慎重に選択されます。

3.2.2 データストレージ要件

展開モード

機密データの状況によって、クラウドストレージの展開モードが決まります。より機密性の高いデータを扱うシステムでは、通常、プライベート展開モードが採用されます。機密性のないデータの場合、クラウドストレージのコストは重要な考慮事項となることがよくあります。パブリッククラウドの導入では、データストレージコストを考慮するだけでなく、ストレージトラフィックコストも考慮する必要があります。

当社のビジネスアプリケーションシナリオを考慮して、クラウドストレージではパブリッククラウドモデルを除外し、代わりにプライベート展開モデルを採用しています。

ストレージアクセスインターフェイス

ストレージアクセスインターフェイスは、クラウドストレージの機能要件に対応しています。当社では、ブロックストレージ、NAS ストレージインターフェイス、オブジェクトストレージ S3 インターフェイスが含まれます。ブロックストレージはクラウドサーバーのハードディスク要件に対応し、NASストレージは複数のクラウドサーバー間のファイル共有要件に対応し、オブジェクトストレージS3インターフェースはインターネット関連ビジネスの非構造化データストレージとコールドデータアーカイブ要件に対応します。

データストレージの階層化

データストレージのグレーディングにより、さまざまなビジネスシステムのストレージ要件を満たすことに基づいて、全体的なクラウドストレージコストを削減できます。当社の事業状況に応じて、以下のように分けられます。最高のストレージ性能と信頼性が求められる基幹業務システムとそのデータベース。 b)。より高いストレージパフォーマンスと信頼性を必要とするその他の軽量データベース。 c)。一定のストレージパフォーマンスと優れたスケーラビリティを必要とする新しいインターネットビジネスやその他の重要でないアプリケーション。 d)。高いスケーラビリティと低いストレージパフォーマンス要件を必要とする非構造化ビジネスデータ。 e)。データのバックアップとアーカイブ、データストレージのホットとコールドの階層化。 f)。古いストレージを再利用した開発およびテストシステム。

3.3 クラウドストレージの全体的なアーキテクチャ

業界の発展傾向と企業の IT 戦略変革の方向から判断すると、当社の伝統的なビジネスは依然として重要な基本的地位を占めており、集中型ストレージアーキテクチャと分散型ストレージアーキテクチャが長期にわたって共存することも決定づけています。分散ストレージアーキテクチャは主に新しいオンラインビジネスシナリオで使用されますが、集中型 SAN ストレージと NAS ストレージは従来のビジネスシナリオで依然として重要な位置を占めています。

最終的に、図 7 に示すように、異機種ストレージリソースを統一的に管理し、大量のデータシナリオ向けに複数の種類のデータインターフェイスを提供するクラウドストレージアーキテクチャが確立されました。ハイパーコンバージドアーキテクチャを導入して IT インフラストラクチャのクラウドベースの変革を実現することで、プライベートクラウド IaaS プラットフォームを構築でき、開発とテスト、新しいインターネットビジネスアプリケーションなどのハイパーコンバージドクラスターを個別に構築できます。半構造化データと非構造化データの膨大な量を処理するには、分散オブジェクトストレージによる弾力的にスケーラブルなデータレイクの構築、ポリシーベースのデータライフサイクル管理の採用、ホット、ウォーム、コールドリソースプールの提供、さまざまなリソースプールとクラウドプラットフォーム間のデータフローと階層化の実現が必要です。

図 7. クラウドストレージアーキテクチャ図

3.4 アーキテクチャ設計の評価

クラウドストレージアーキテクチャの設計が合理的かどうかは、感度ポイント、トレードオフポイント、アーキテクチャリスクポイントの 3 つの側面から評価する必要があります。

敏感なポイント

敏感なポイントは、ストレージハードウェアとソフトウェアのコスト、信頼性、ストレージ IO パフォーマンス、アーキテクチャの複雑さ、柔軟な拡張機能、リソースアイランド、障害ドメインの分離、管理性など、さまざまなデータストレージのいくつかの共通の特性に対応します。

トレードオフ

トレードオフポイントは、複数のアーキテクチャ品質属性に影響する敏感なポイントであり、建築家がトレードオフを評価する必要があります。たとえば、ストレージアーキテクチャが集中型か分散型かによって、ストレージアーキテクチャの複雑さと柔軟な拡張機能が決まります。ストレージのソフトウェアとハードウェアのコストも、ストレージの信頼性とパフォーマンスを大きく左右します。リソースアイランドはリソースの無駄を引き起こす可能性がありますが、合理的な計画は障害ドメイン分離の前提条件でもあります。

リスクポイント

建築家にとって、最も注意すべきことは、建築設計の成否の鍵となる建築物のリスクポイントです。分散ストレージアーキテクチャには、複雑性の高さ、新しいテクノロジの導入のリスク、バージョンの反復が速いなどのリスクがあります。ハイパーコンバージドアーキテクチャは、スケーラビリティの制限やリソースの孤立などのリスクにも直面します。従来のストレージアーキテクチャの主なリスクポイントは、膨大なデータストレージの拡張に対応することが難しく、コストが高く、新しいテクノロジへの適応性が高くないことです。

当社のクラウドストレージアーキテクチャ設計に対応する従来の SAN ストレージは、パフォーマンスが安定しており、IO レイテンシが低く、コストが高く、拡張が容易ではありませんが、コアビジネスシナリオに適しています。 NAS ストレージのパフォーマンスは高くありませんが、ファイルの使用と共有が簡単で、コストも高くないため、ほとんどのファイル共有およびアクセスシナリオに適しています。分散オブジェクトストレージのパフォーマンスは平均的で、アーキテクチャは非常に複雑ですが、柔軟に拡張でき、大量のデータストレージをサポートし、コストが低いため、大規模な構造化データストレージやインターネットビジネスシナリオに適しています。ハイパーコンバージドアーキテクチャは、コンピューティングリソースと適切に統合でき、アーキテクチャがシンプルで、コストが低くなります。スケーラビリティの制限やリソースの孤立といった問題はあるものの、企業のビジネスとコンピューティングリソースの比率に合わせてさまざまなハイパーコンバージドクラスターを構築することで、データストレージのグレーディングを適切に行い、さまざまな障害ドメインを分離することができます。

3.5 技術の選択

クラウドストレージアーキテクチャ設計評価によると、当社では、分散オブジェクトストレージとハイパーコンバージェンスという、異なるハードウェアアーキテクチャを備えた 2 つのクラウドストレージソリューションも導入する必要があります。クラウドストレージの基盤となるストレージテクノロジの分析と組み合わせると、分散オブジェクトストレージは、パフォーマンス要件が低く、スケーラビリティが強い分散キー値ストレージに基づく製品に適しています。ハイパーコンバージェンスは、より明確な論理アーキテクチャを備えた分散ファイルシステムに基づく傾向があり、超大規模な展開は追求しませんが、小規模な展開ではパフォーマンス上の利点が多くあります。

従来の業界では、オープンソースのクラウドストレージテクノロジーをそのまま使用することはできず、さまざまなビジネスシステムのストレージニーズには適していません。クラウドストレージなどのインフラ分野では技術的な自立を達成することが非常に難しく、それに応じた技術の蓄積、人材チームの構築、研究開発リソースの投資が不足しています。したがって、ほとんどの従来の企業は、さまざまなメーカーのクラウドストレージ製品を選択する必要があり、テクノロジの選択は、さまざまなメーカーの製品を選別することを意味します。

さまざまなメーカーの分散ストレージには、それぞれ明確な市場ポジショニングと有利なシナリオがあります。その中で、ストレージ製品のコア技術を管理するメーカーの能力が最も重要であり、次にメーカーのアフターサービスレベル、そしてもちろん製品の価格レベルが続きます。当社のような中小企業の場合、戦略に沿って、同業他社でトップクラスのシェアと大規模な導入事例を持つメーカーの製品を選定することを好みます。

メーカーの製品を選択した後も、技術選択を確認するために技術レベルで POC テストが必要です。クラウドストレージ製品の場合、選択テストでは次の 6 つの点を考慮する必要があります。