アクティブ/アクティブアーキテクチャ：究極ガイド
アクティブ/アクティブアーキテクチャとは、複数のサーバーまたはノードが同時に稼働し、ワークロードを分散することで高可用性を確保するシステム設計です。この構成はダウンタイムを排除し、パフォーマンスを向上させ、容易に拡張できるため、eコマースや金融サービスなどの重要なアプリケーションに最適です。知っておくべきポイントは以下のとおりです。
- 可用性: 単一障害点がなく、自動フェイルオーバーによりシステムは中断することなく稼働し続けます。
- 性能: 負荷分散により、トラフィックの急増時でも一貫した応答時間が保証されます。
- 拡張性: 変化する需要に対応するために、必要に応じてサーバーを追加または削除します。
- 地理的範囲: 異なる場所にあるサーバーにより、待ち時間が短縮され、災害復旧がサポートされます。
アクティブ/アクティブシステムは比類のない信頼性を提供しますが、インフラコストの上昇、データ整合性の問題、管理の複雑さといった課題も伴います。アクティブ/アクティブとアクティブ/パッシブのどちらを選択するかは、予算、技術的専門知識、そしてアプリケーションのニーズによって異なります。ミッションクリティカルなシステムの場合、アクティブ/アクティブは投資に見合う価値がある場合が多いです。
アクティブ・アクティブ・フェイルオーバー | システム設計の芸術
アクティブ-アクティブサーバー構成の利点
アクティブ/アクティブサーバー構成は、可用性とパフォーマンスの面で顕著なメリットをもたらします。この構成がお客様のビジネスニーズと技術ニーズをどのように満たすことができるか、詳しく見ていきましょう。
継続的な可用性とフェイルオーバー
アクティブ・アクティブアーキテクチャの際立った利点の1つは、 中断のないサービス個々のコンポーネントに障害が発生した場合でも、アプリケーション全体が停止する可能性があります。従来の構成では、単一のサーバーに障害が発生するとアプリケーション全体が停止する可能性がありますが、アクティブ/アクティブシステムでは、ワークロードを複数のアクティブノードに分散します。
1台のサーバーに問題が発生したり、メンテナンスが必要になったりしても、他のサーバーがシームレスにその役割を担います。この自動フェイルオーバーにより、ユーザーは中断に気付くことなく、ダウンタイムを効果的に排除し、 安定した稼働時間.
eコマース、金融サービス、その他ビジネスクリティカルなアプリケーションといった業界では、この信頼性により、システム停止に伴う収益損失を大幅に削減できます。アプリケーションは24時間アクセス可能であり、これはユーザーの信頼と満足度を維持するために不可欠です。
さらに、この構成により、可用性を損なうことなくメンテナンスの頻度を高めることができ、システム全体の健全性向上に貢献します。信頼性に加え、アクティブ/アクティブ構成は、高負荷時のパフォーマンス管理にも優れています。
負荷分散とパフォーマンスの向上
アクティブ/アクティブシステムでは、すべてのサーバーがトラフィックをアクティブに処理するため、単一のノードがボトルネックになることはありません。このバランスの取れたアプローチにより、応答時間が一定に保たれ、システムの過負荷を防止できます。ユーザーは、ページの読み込み速度、データベースクエリの高速化、そして全体的な応答性の向上といったメリットを享受できます。
この利点は、 交通量のピーク時季節のセールやバイラルコンテンツの急増など、さまざまな状況で発生します。複数のアクティブサーバーが連携し、大量のトラフィックを処理できます。速度低下やクラッシュは発生しません。この機能は、ユーザーアクティビティの急増が予想される企業にとって特に重要です。
さらに、アクティブ/アクティブ構成はハードウェアを最大限に活用します。バックアップサーバーをアイドル状態のままにするのではなく、すべてのサーバーが処理能力に貢献することで、リソース利用率を最大化します。つまり、単一サーバー構成と比較して、インフラストラクチャのパフォーマンスが向上し、より多くの価値を引き出すことができます。
スケーラビリティと地理的範囲
リソースの効率的な利用とワークロードのバランスにより、アクティブ/アクティブシステムは高いスケーラビリティを実現します。スケーリングはクラスターにサーバーを追加するだけで簡単に行えます。この水平スケーリングアプローチにより、インフラストラクチャはビジネスに合わせて拡張でき、需要の増加にも容易に対応できます。
さらに、スケーリングは双方向に機能します。混雑時にはスケールアップし、閑散時にはスケールダウンすることで、パフォーマンスを犠牲にすることなくコストを最適化できます。この柔軟性により、インフラストラクチャをニーズに合わせて調整できます。 変化するビジネスニーズ 大規模な改修を必要とせずに。
もう一つの重要な利点は、サーバーを分散できることです。 複数の地理的場所アクティブサーバーを異なる地域やデータセンターに展開することで、アプリケーションをユーザーの近くに配置でき、レイテンシを削減し、ユーザーエクスペリエンスを向上させることができます。ユーザーは自動的に 最も近い利用可能なサーバーより速い応答時間を保証します。
地理的な分散は災害復旧にも役立ちます。自然災害や技術的な問題で1つのデータセンターがオフラインになった場合でも、他の拠点のサーバーが中断することなくトラフィック処理を継続します。さらに、 データ保管要件アクティブ/アクティブ設定のパフォーマンスと可用性のメリットを享受しながら、ユーザー データが特定の地理的境界内に留まるようにします。
次のような解決策により、 Serverionグローバル データ センターを活用して、アプリケーションにエンタープライズ グレードのパフォーマンスと信頼性を実現できます。
設計原則と実装戦略
堅牢なアクティブ/アクティブ・アーキテクチャを構築するには、ワークロードの管理、データの一貫性の確保、そして回復力のあるインフラストラクチャの構築に関する明確な計画が必要です。システムの有効性は、これらの要素がいかに適切に実装され、アクティブ/アクティブ構成ならではのシームレスなパフォーマンスを実現できるかにかかっています。
分散ワークロード管理
あらゆるアクティブ・アクティブシステムの中心となるのは 効率的な作業負荷分散ロードバランサーはトラフィックコントローラーとして機能し、各リクエストをどのサーバーで処理するかを決定します。多くの場合、単一の分散方法に頼るのではなく、複数の分散方法を組み合わせることで、最良の結果が得られます。
- ラウンドロビン ユニフォームサーバーに適しています。
- 加重ラウンドロビン 容量の異なるサーバーに合わせて調整します。
- 最小接続 動的な環境に最適で、アクティブな接続が少ないサーバーが新しいタスクを実行できるようにします。
複数の場所にサーバーを設置する場合、 地理的ルーティング 必須です。例えば、ニューヨークのユーザーは東海岸のサーバーに接続し、カリフォルニアのユーザーは西海岸のサーバーに接続します。これにより、ユーザーがアクセスするサーバーに近くなるため、レイテンシが削減され、パフォーマンスが最適化されます。
定期的なヘルスチェックは不可欠です。ハートビート間隔を5～10秒に設定すると、システムは障害が発生したノードを迅速に特定し、ローテーションから削除することで、すべての動作をスムーズに維持できます。
セッション管理 アクティブ/アクティブ環境では扱いが難しい場合があります。スティッキーセッション（セッションアフィニティとも呼ばれます）はサーバー負荷の不均一化につながる可能性がありますが、 セッションレプリケーション ノード間のトラフィックが増えると、ネットワークトラフィックが増加します。より良い方法は、 外部セッションストア Redisや専用のセッションデータベースなど。これにより、スティッキーセッションや過剰なレプリケーションに頼ることなく、どのサーバーでもユーザーリクエストを処理できます。
トラフィックが効果的に分散されたら、次の課題はすべてのアクティブ ノード間で一貫したデータを維持することです。
データの同期と一貫性
複数のアクティブノード間でデータの一貫性を維持するには、パフォーマンスと信頼性のバランスを取ることが重要です。同期戦略の選択は、アプリケーションが一時的な不整合をどの程度許容できるかによって異なります。
- 同期レプリケーション トランザクションを完了する前にすべてのノードがデータ書き込みを確認することで、リアルタイムの一貫性を保証します。ただし、すべての操作がすべてのノードからの確認を待つため、レイテンシが増加します。
- 非同期レプリケーション プライマリノードへの書き込みが完了するまで他のノードに伝播させないことで、速度を優先します。このアプローチでは一時的な不整合が発生しますが、応答時間を大幅に短縮できます。多くのアプリケーションでは、レプリケーション遅延が100ミリ秒未満であれば、この方法は許容範囲内です。
どのノードでも書き込みを許可するシステムの場合、 マルチマスターレプリケーション 柔軟性とパフォーマンスは向上しますが、強力な競合解決メカニズムが必要になります。単純なケースでは、 最後に書いた人が勝つ より複雑なシナリオでは、次のような高度な技術が必要になる場合があります。 ベクトルクロック または 業務変革.
CockroachDB のような分散環境向けに設計されたデータベースは、一貫性管理を簡素化します。これらのシステムはコンセンサスアルゴリズムを使用してデータの正確性を維持しながら、高い可用性を確保します。もう一つの選択肢は イベントソーシング変更は直接的な更新ではなく、不変のイベントとして保存されます。この方法は、ノードがイベントログから状態を再構築できるため、一貫性を簡素化し、組み込みの監査証跡を提供します。
インフラストラクチャとネットワークの要件
バランスの取れたワークロードと一貫性のあるデータは、それらを支えるインフラストラクチャによってのみ、その効果を発揮します。アクティブ/アクティブアーキテクチャでは、安定した運用と予期せぬ障害の両方に対応できるハードウェアとネットワーク構成が必要です。
ネットワーク遅延 特に同期操作においては、これは重要な要素です。ノード間のレイテンシを10ミリ秒未満に抑えることで、ユーザーにとって応答性の高いエクスペリエンスが保証されます。同様に、 帯域幅計画 は不可欠です。同期レプリケーションでは、特にユーザーリクエストとレプリケーショントラフィックの両方が急増するピーク時には、標準的なアプリケーショントラフィックの2～3倍の帯域幅が必要になることがよくあります。
あなたの ストレージシステム データの整合性を損なうことなく、複数のノードからの同時アクセスを処理する必要があります。 共有ストレージシステム SAN は一貫性を確保できますが、ボトルネックになる可能性もあります。 分散ストレージ より優れたスケーラビリティを提供しますが、競合を防ぐために慎重な調整が必要です。
ダウンタイムを回避するために、 ネットワーク冗長性 が鍵です。ノード間の複数のネットワークパスにより、単一障害点が排除され、 自動フェイルオーバー 業務の中断時でも円滑な継続を確保します。プライマリとバックアップの両方の通信チャネルを整備する必要があります。
監視も同様に重要です。 集中ログ そして 分散トレース サーバー全体の問題を特定し、 リアルタイムダッシュボード 各ノードの健全性とパフォーマンスを明確に把握できます。このプロアクティブなアプローチにより、問題が深刻化する前に対処できます。
アクティブ/アクティブ設定ではセキュリティがより複雑になります。 証明書管理 複数のアクティブなエンドポイントを考慮する必要があり、 アクセス制御 すべてのノード間で一貫して機能する必要があります。さらに、ノード間通信を暗号化することで、レプリケーション中の機密データを保護します。
強力な基盤を求める人にとって、Serverion のグローバル データ センター ネットワークを活用することで、低遅延の接続と冗長インフラストラクチャが保証され、これらの原則を効果的に実装しやすくなります。
sbb-itb-59e1987
アクティブ/アクティブ展開における課題
アクティブ/アクティブアーキテクチャには多くの利点がありますが、最も準備の整った組織でさえも驚かされるような独自の障害も存在します。規模が大きくなるにつれて複雑さも増し、数ノードでは問題なく機能するものでも、複数のリージョンに数十ノードが分散すると、たちまちロジスティクス上の頭痛の種になってしまいます。
管理の複雑さと監視
アクティブ/アクティブシステムの管理は、ノードが追加されるにつれてますます複雑になります。従来の監視ツールでは、分散システム全体に必要な調整に対応できないことがよくあります。
想像してみてください。1つのトランザクションが複数のノードを通過する可能性があり、それぞれのノードには独自の癖や潜在的なボトルネックがあります。このようなシナリオのトラブルシューティングには時間がかかり、高度な分散トレースツールが必要です。もはや個々のノードをチェックするだけでは不十分です。ノード間の通信を監視し、データの整合性を確保する必要があります。このようなレベルの監視には、ノード間のデータを相関させ、問題を正確に特定できる専用のツールが必要です。
もう一つの課題は、設定のずれです。複数のアクティブノードを扱う場合、設定のわずかな不一致でも予期せぬ動作を引き起こす可能性があります。そのため、すべての同期を維持するには、厳格な変更管理と自動化されたデプロイメントパイプラインが不可欠です。
運用チームにとって、学習曲線は急峻です。分散システムの概念、コンセンサスアルゴリズム、そして紛争解決戦略を習得する必要があります。これらのスキルは、トレーニングと実務経験の両方を必要とします。加えて、アラート疲れの問題も存在します。アラートを生成するノードが非常に多いため、特に一時的なネットワーク障害などの些細な問題が誤報を引き起こすと、チームは容易に圧倒されてしまいます。通知の氾濫を避けるため、アラートのしきい値を微調整することが不可欠です。
インフラコスト
アクティブ/アクティブ構成は、運用上の専門知識を必要とするだけでなく、莫大なインフラコストも伴います。その経済的影響は、単にサーバーを追加するだけでは済まされません。各ノードには、本番環境の負荷に対応するために必要なコンピューティング能力、メモリ、ストレージが十分に備わっていなければなりません。スタンバイリソースが最小限で済むアクティブ/パッシブシステムとは異なり、アクティブ/アクティブシステムでは完全な冗長性が求められるため、コストが大幅に上昇します。
ストレージ費用も増加します。共有ストレージシステムであれ分散ストレージソリューションであれ、すべてのノードは正確なデータにリアルタイムでアクセスする必要があります。特に地理的に離れた場所間で、このレベルの同期を確保するには、全体的な費用が増大します。
さらに、運用上のオーバーヘッドも存在します。アクティブ/アクティブ環境では、24時間365日体制の運用サポートと専門知識が求められることが多く、追加のスタッフの雇用や大規模なトレーニングへの投資が必要になる場合があります。多くのソフトウェアベンダーはアクティブインスタンスごとにライセンス料を請求するため、ライセンス料もかさみ、ノードが増えるごとにコストが増大します。
テスト環境は、もう一つの経済的なハードルとなります。信頼性を確保するためには、ステージング環境のセットアップは本番環境の複雑さを反映する必要があり、テスト専用の追加インフラストラクチャが必要になります。
データの競合とスプリットブレインシナリオ
アクティブ/アクティブシステムにおいてデータの整合性を維持することは容易ではありません。複数のノードが同時に書き込みを受け入れると、必然的に競合が発生し、それを適切に解決するには高度な戦略が必要です。
例えば、2人の顧客が同時に在庫レベルを更新したとします。適切な競合解決を行わないと、商品の過剰販売につながる可能性があり、これはどの企業にとっても悪夢です。
スプリットブレインシナリオも大きな懸念事項です。これは、ネットワークの分断によってノードグループが分離され、各グループが他のグループに障害が発生したと想定した場合に発生します。両方のグループが独立して書き込み処理を継続するため、データ状態の競合が発生し、調整が困難になります。これらの問題を解決するには、多くの場合手動による介入が必要となり、システムの可用性が低下する可能性があります。
これらの課題に対処するために、Last Write Wins（最終書き込み優先）やMulti-Version Concurrency Control（多版型同時実行制御）といった戦略が活用されます。しかし、これらのアプローチは、シンプルさとデータの正確性の間でトレードオフを伴います。すべてのノードがすべての書き込みに対して協調動作を行う強整合性モデルは、データの整合性を保証しますが、パフォーマンスが低下する可能性があります。一方、結果整合性モデルはパフォーマンスを向上させますが、一時的な不一致を許容します。適切なバランスを見つけるには、広範なテストと微調整が必要です。
ネットワーク分断への対応は、さらに複雑な要素を伴います。システムは、（不整合のリスクを負っても）書き込みを継続することで可用性を優先するか、問題が解決するまで一時的に書き込みを拒否することで一貫性を維持するかを判断する必要があります。
データ競合からの復旧は、ほとんどの場合容易ではありません。影響を受けたデータを特定し、不一致を解決し、すべてのノード間で修正を同期するには、システムの一部をオフラインにする必要があることが多く、皮肉なことに、アクティブ/アクティブアーキテクチャが実現する高可用性が損なわれてしまいます。
これらの課題こそが、多くの組織がシンプルなアーキテクチャからスタートし、経験を積むにつれて徐々にアクティブ/アクティブ構成に移行する理由です。すぐに導入する準備ができている組織にとって、Serverionのようなプロバイダーと提携することで、グローバルデータセンターネットワークを通じて専門家のサポートと実績のある導入戦略が提供され、プロセスを容易にすることができます。
アクティブ/アクティブとアクティブ/パッシブの比較
アクティブ/アクティブアーキテクチャとアクティブ/パッシブアーキテクチャのどちらを選択するかは、技術的な考慮事項にとどまりません。インフラストラクチャ、予算、そしてユーザーエクスペリエンスに影響を与える戦略的な決定です。どちらのアーキテクチャにも長所があり、その違いを理解することで、運用上の優先事項に合わせて選択を絞り込むことができます。
機能比較表
2 つのアーキテクチャの比較を次に示します。
| 特徴 | アクティブ-アクティブ | 能動態-受動態 |
|---|---|---|
| 可用性 | ほぼ瞬時のフェイルオーバーによる極めて高い稼働率 | 稼働時間は長いが、フェイルオーバーによる遅延が短時間発生する可能性がある |
| フェイルオーバー速度 | ほぼ瞬時に | フェイルオーバー中に若干の遅延が発生する |
| リソースの利用 | すべてのアクティブノードを最大限に活用 | スタンバイノードは十分に活用されていない |
| インフラコスト | すべてのノードの同時操作により高くなる | アイドル状態のバックアップノードでコスト効率を向上 |
| 運用の複雑さ | 高度な専門知識と設定が必要 | 標準ツールで管理が簡単 |
| 性能 | 負荷分散により応答時間が改善されます | 集中処理はボトルネックを引き起こす可能性がある |
| 地理的分布 | マルチリージョン展開を自然にサポート | 同様の到達範囲を得るには追加の設定が必要 |
| データの一貫性 | 複雑な同期により一貫性が遅れる可能性がある | よりシンプルで、より強い一貫性 |
| メンテナンスウィンドウ | 中断を最小限に抑えたローリングアップデート | 通常は計画的なダウンタイムが必要 |
この比較は、これらのアーキテクチャの選択が可用性、パフォーマンス、そしてコストにどのような影響を与えるかを示しています。たとえ短時間のダウンタイムであっても収益の損失につながる企業にとって、アクティブ/アクティブ構成のメリットは、複雑さの増加を上回る場合が多いです。
アクティブ/アクティブとアクティブ/パッシブの選択
適切なアーキテクチャはビジネスニーズによって異なります。金融取引やリアルタイム通信といったミッションクリティカルなアプリケーションの場合、ダウンタイムを最小限に抑えられるアクティブ/アクティブシステムが最適です。ただし、複雑さとコストが増大するため、このアプローチはすべての組織にとって現実的ではない可能性があります。
小規模企業やスタートアップ企業では、アクティブ/パッシブアーキテクチャがより費用対効果が高く、管理しやすい出発点となることがよくあります。運用規模が拡大し、ダウンタイムのコストが増大するにつれて、アクティブ/アクティブモデルへの移行は論理的な次のステップとなる可能性があります。
ユーザーベースが複数のリージョンに分散している場合、アクティブ/アクティブ構成では、トラフィックを最も近いノードにルーティングすることでレイテンシを削減し、応答時間を改善することでパフォーマンスを向上させることができます。一方、アクティブ/パッシブシステムでは、同様の結果を得るために追加のカスタマイズが必要になる場合があります。
アプリケーションの性質も重要な役割を果たします。書き込み中心のシステムは、アクティブ/アクティブ環境での同期の問題に悩まされる可能性がありますが、読み取り中心のアプリケーションは分散リソースを活用することで問題なく動作します。
分散システムを初めて導入する組織は、アクティブ/パッシブ構成から始めることで、必要な専門知識を習得できます。Serverionのような経験豊富なプロバイダーの支援を受けながら、時間をかけてアクティブ/アクティブ構成を段階的に導入していくことができます。Serverionは、グローバルなデータセンターネットワークと分散システムの専門知識を提供しています。これにより、チームはインフラストラクチャの課題に煩わされることなく、最高レベルのアプリケーションの提供に集中できます。
結論
アクティブ/アクティブ アーキテクチャは、比類のない稼働時間、優れたパフォーマンス、スムーズな地理的分散を提供し、一瞬のダウンタイムでも収益の損失につながる可能性があるミッション クリティカルなアプリケーションに最適な選択肢となります。
その際立った利点のいくつかは次のとおりです。 回復時間ゼロ, 自然な負荷分散, 水平スケーラビリティ、 そして より良いROI リソースのフル活用とレイテンシの低減により、データセンターは大きなメリットをもたらします。しかし、これらのメリットには独自の課題も伴います。設計と実装ははるかに複雑で、専門家による監督と継続的な監視が必要です。さらに、複数のアクティブサーバー、高度なロードバランサー、ハイエンドのネットワーク機器が必要となるため、インフラコストは増加する傾向があります。また、データ同期は、よりシンプルな構成であれば完全に回避できるような一貫性の問題を引き起こす可能性があります。
アクティブ/アクティブと他のアーキテクチャのどちらを選択するかを決める際には、ビジネス目標と利用可能なリソースに合わせて選択することが重要です。アクティブ/アクティブは、ダウンタイムをほぼゼロに抑えることが求められるアプリケーションに最適ですが、アクティブ/パッシブは、予算が限られている場合や、ニーズがそれほど複雑でない場合はより適している可能性があります。
アクティブ/アクティブアーキテクチャがお客様の優先事項と合致する場合、経験豊富なプロバイダーとの提携が大きな違いをもたらします。Serverionのグローバルデータセンターと分散システムの専門知識を活用することで、導入を簡素化し、コアビジネスに集中できます。実績のあるインフラストラクチャソリューションは、複数の拠点にわたる高可用性を確保し、システムが最も重要なタイミングで確実に機能することをお約束します。
信頼性とパフォーマンスが譲れないビジネスにとって、アクティブ/アクティブ アーキテクチャは賢明な投資です。
よくある質問
アクティブ/アクティブ アーキテクチャとアクティブ/パッシブ アーキテクチャの違いは何ですか? また、パフォーマンスとコストにどのような影響がありますか?
アクティブ・アクティブアーキテクチャは、複数のノードで同時にワークロードを共有し、 強力なパフォーマンス そして ダウンタイムの短縮トレードオフは何でしょうか？ 追加のハードウェア、複雑な構成、そしてそれらを管理するために継続的に必要な労力のために、コストが高くなることがよくあります。
対照的に、アクティブ・パッシブ構成はより 予算に優しい オプションです。セカンダリノードは、必要なときまでスタンバイ状態を維持します。このアプローチは運用コストを削減しますが、フェイルオーバー時に若干の遅延が発生する可能性があり、アクティブ/アクティブシステムのパフォーマンスレベルには及びません。この2つのどちらを選択するかは、稼働時間とパフォーマンスを優先するか、コストを抑えるかなど、お客様のニーズに応じて決定してください。
アクティブ/アクティブ アーキテクチャはどのようにしてデータの一貫性を維持し、複数のノード間での競合を解決するのでしょうか?
アクティブ・アクティブアーキテクチャは、次のようなツールを使用してデータの一貫性を維持し、競合を処理します。 タイムスタンプ または シーケンシング データの最新版または信頼できるバージョンを識別します。これらの方法により、ノード間の更新がリアルタイムで管理されます。
紛争を解決するための戦略としては、 自動プロセス, 手動レビュー、 または ユーザー定義のカスタムルールこれらのアプローチは、特にマルチリージョンやマルチマスター環境などの複雑な設定において、同期を維持し、競合を減らすために機能します。
アクティブ/アクティブ アーキテクチャを正常に実装するには、どのようなインフラストラクチャとネットワーク設定が必要ですか?
アクティブ・アクティブアーキテクチャを正常に導入するには、インフラストラクチャがすべてのデータセンターまたはリージョンで同時に本番環境トラフィックを管理できるようにする必要があります。この構成は、 大容量、低遅延の接続 データをリアルタイムで同期し、ダウンタイムのリスクを軽減します。
ネットワークの観点から見ると、 レイヤー2（L2）接続 サイト間のデータレプリケーションは、スムーズなデータ複製に不可欠です。これに加え、堅牢な仮想化と相互接続戦略の実装は、システムの耐障害性と中断のない可用性を確保する鍵となります。これらの要素に重点を置くことで、要求の厳しいシナリオにおいても一貫したパフォーマンスを維持できます。
