クラウドネイティブデータシステムの設計上の考慮事項

翻訳者 |陸新王

校正：孫淑娟

クラウドネイティブデータシステムを設計する場合、特定のホスティングインフラストラクチャ、プログラミング言語、または設計パターンは必要ありません。クラウドネイティブシステムを構築する方法は多数あります。クラウドネイティブアーキテクチャが留意すべき設計原則と、優れたクラウドネイティブプラットフォームの特徴について見てみましょう。

1. クラウドネイティブアーキテクチャ

クラウドネイティブアーキテクチャは、本質的にはクラウドを使用してアプリケーションを構築するための設計パターンです。このアーキテクチャや事前定義されたクラウドネイティブデザインを実装する特定の方法はありませんが、最も一般的なアプローチは、アプリケーションを複数のマイクロサービスに分解し、各マイクロサービスが異なるタイプの機能を処理することです。各マイクロサービスは小規模なチームによって保守され、通常はコンテナとしてデプロイされます。

クラウドネイティブアーキテクチャを詳しく見てみましょう。

2. マイクロサービスを採用する

クラウドネイティブの設計と開発は、多くの場合マイクロサービスを使用して、アプリケーションのさまざまな部分が独立して開発、運用、およびデプロイされる、疎結合アーキテクチャに依存しています。

マイクロサービスはクラウドネイティブシステムの基盤であると言っても過言ではありません。コンテナを使用すると、ランタイム環境とそのライブラリ、バイナリ、依存関係を論理的で管理しやすい単位に圧縮できるというメリットが得られます。したがって、アプリケーションサービスは必要に応じて保存、コピー、転送、および使用できます。

モノリシックプログラムとは異なり、マイクロサービスは小さく独立したサービスで構成されています。

マイクロサービス (または疎結合アーキテクチャ) は、クラウドコンピューティングにとって非常に重要です。これには、サービスのシンプルさ、スケーラビリティ、回復力が向上するなど、いくつかの理由があります。これがどのように実現されるのか、詳しく見てみましょう。

このアーキテクチャを使用すると、複雑なアプリケーションを小さな独立したモジュールに分割して、アプリケーション開発サイクルをシンプルかつ管理しやすいものにすることができます。アプリケーション構成と基本コードを分離すると、アプリケーションの開発と保守も容易になります。同様に、コアアプリケーションをサポートサービスから分離しておくことで、コードベースを独自のペースで進化させ、拡張することができます。

さらに、モノリス全体をスケーリングするよりも、アプリケーションの一部をスケーリングする方が簡単 (かつ高速) です。同様に、アプリケーション全体の新しい更新バージョンを再度デプロイするのではなく、変更が必要な部分 (またはマイクロサービス) のみを更新する必要があるため、アプリケーションの更新が簡単になります。

マイクロサービスを採用すると回復力も向上し、アプリケーションの信頼性も高まります。たとえば、マイクロサービスアーキテクチャ内の 1 つのコンポーネントに障害が発生しても、アプリケーション全体がクラッシュすることはありません。また、IaC (Infrastructure as Code) も促進され、自動デプロイメント (後ほど説明します) への道が開かれます。最後に、マイクロサービスアーキテクチャでは、API を介してステートレスプロセスとコンポーネントを使用して各マイクロサービスを他のサービスから分離し、セキュリティと効率を向上させます。

アプリケーションが疎結合アーキテクチャに従うようにするには、異なる部分間で密結合の依存関係が形成されないようにする必要があります。たとえば、2 つのマイクロサービスが同じデータベースに依存してはなりません。そうすると、独立して更新したり操作したりすることができなくなります。

3. コードがすべて

最新のアプリケーションの利点を活用するにはマイクロサービスを使用することが重要ですが、自動化のプラクティスを採用することも重要です。これは、アプリケーション開発プロセスを最適化し、開発者とユーザーの両方にメリットをもたらすことを目的としています。この目的を達成するために、最終的な目標は EaC (Everything as Code) を実現することです。したがって、EaC は IaC より一歩進んだものと考えてください。IaC には、アプリケーションコードベース、インフラストラクチャ、プラットフォームが含まれます。

このアプローチには、ハードウェアとソフトウェアの両方で多くの利点があります。たとえば、あらゆるレベルでバージョン管理を実施し、部門間のコラボレーションを向上させるのに役立ちます。また、さまざまなコンポーネントのモジュール化を促進し、タイムリーな更新を通じて脆弱性を防ぐことでセキュリティを強化します。

クラウドネイティブデータシステムの重要な側面は、CI/CD ツールを使用してさまざまなレベルで自動化できることです。 DevOps とアジャイル原則を採用することで、運用コストの削減、セキュリティの向上、柔軟性とスケーラビリティの向上、開発サイクルの高速化などのメリットが得られます。

安全性は特に重要です。手動プロセスはクラウドネイティブプラットフォームへの攻撃につながることがよくありますが、自動化を通じてセキュリティのベストプラクティスを実装すると、セキュリティを強化できます。さらに、CI/CD の SecDevOps を使用すると、SDLC の初期段階でセキュリティテストを実行できるため、開発フェーズの早い段階で脆弱性に対処できます。

4. APIファーストの考え方

開発者は、API ファーストのアプローチではなく、コードファーストの開発アプローチに重点を置くことがよくありますが、問題は、このアプローチが最新のアプリケーションを開発するための最良の方法ではないということです。クラウドネイティブデータシステムの場合、開発者が API ファーストの考え方と開発アプローチを採用し、これに基づいてソフトウェアを構築することを奨励する必要があります。そうすることで、最新の分散アプリケーションの基盤を構築するときに多くの時間と労力を節約できます。

前述したように、クラウドネイティブデータシステムは、アプリケーションのサービスが分離され、各サービスが自律的なアプリケーションとして実行されるマイクロサービスアーキテクチャに従う必要があります。したがって、マイクロサービスは相互に通信および対話するために API に依存します。

マイクロサービスアーキテクチャと最新のアプリケーションの人気を考慮すると、API の重要性は明らかです。さらに、API ファーストの原則により、開発者はマイクロサービスモデルのすべての利点を享受できます。 API ファーストアプローチに従うアプリケーションは、緊密に接続されたサービスのエコシステムと見なすことができ、アプリケーションとユーザーインターフェイスからの呼び出しは API コンシューマーと見なされます。

このアプローチには多くの利点があります。たとえば、システムのスケーラビリティが向上し、障害の可能性が低減します。また、開発コストを削減し、開発エクスペリエンスを向上させ、開発プロセスを加速することで市場投入までの時間を短縮します。 API を通じてユーザーとアプリケーション間の通信を容易にするだけでなく、内部プロセスの自動化と通信も容易にします。

5. クラウドネイティブ設計の原則

クラウドネイティブアプリケーションは通常、12 要素アプリケーションフレームワークで定義された原則に従い、セキュリティ、回復力 (および可用性)、弾力性、パフォーマンス (スケーラビリティを含む) を中心に構築されます。これらのクラウドネイティブ設計の原則を詳しく見てみましょう。

1. スケーラビリティ

スケーラビリティの背後にある考え方は、需要と負荷の増加に応じて、アプリケーションと関連サービスに追加の容量を追加できるというものです。特に、スケーラビリティを設計する場合は、各アプリケーション層、スケーリング方法、ボトルネックの回避方法を考慮する必要があります。

この場合、考慮すべき重要な領域は、容量、負荷、データの 3 つです。

容量に関しては、さまざまな層を拡張する必要があるかどうか、またアプリケーションの可用性に影響を与えずに拡張できるかどうかを検討します。また、サービスをどれだけ迅速に拡張できるか、また、業務に影響を与えずにサービス停止中にアプリケーションの展開を縮小できるかどうかも考慮する必要があります。

データに関しては、トランザクションスループットやデータベースサイズなどのサービスの制限を念頭に置いて、拡張可能かどうかを検討してください。次に、プラットフォームの制約を維持しながら、スケーラビリティをさらに向上させるためにデータをどのように分割するかを検討します。同様に、プラットフォームリソースを効率的に使用する方法を検討する必要があります。

負荷側では、ボトルネックを回避するために設計を改善する方法と、トラフィックの急増時に負荷分散を支援するために非同期操作を使用する方法を決定する必要があります。また、選択したプラットフォームのさまざまなレートバランシング機能と負荷分散機能の使用方法についても検討する必要があります。

スケーラビリティを確保する 1 つの方法は、必要に応じてシステムを拡張、修復、展開するための自動化されたプロセスを作成することです。意味のあるログ (およびイベント) を生成するようにシステムを設定し、それをさまざまな自動化アクティビティのフックとして使用することができます。結果として得られるシステムは、マシンインスタンスなどのインフラストラクチャを自動的にプロビジョニングし、CI/CD パイプラインのさまざまなステージを構築、テスト、デプロイし、動的なスケーラビリティとヘルスモニタリングおよびバックアップを処理できる必要があります。

多くの人は、クラウドネイティブシステムはステートレスであるべきだと考えていますが、実際のアプリケーションではこれを実現するのは困難です。分散アプリケーションでは状態を管理するのが難しいため、可能な限りステートレスコンポーネントを使用するのが最適です。これは、ステートレスコンポーネントによって負荷分散、スケーリング、修復、ロールバックが容易になるためです。

2. 可用性

可用性とは、基盤となるオペレーティングシステム、ハードウェア、ネットワーク依存関係、またはアプリケーション自体に障害が発生した場合でも、消費者がシステムを利用できる状態を維持する能力を指します。重要な原則には、パフォーマンス、稼働時間、災害復旧、バックアップが含まれます。

パフォーマンスに関しては、許容可能なパフォーマンスレベル、その測定方法、パフォーマンスが許容レベルを下回った場合にトリガーされるアクションまたはイベントを定義する必要があります。また、問題を引き起こす可能性が最も高いアプリケーションの部分を特定し、キュー中心の設計や自動スケーリングが問題の解決に役立つかどうかも特定する必要があります。さらに、クラウドネイティブシステムの一部を非同期にするとパフォーマンスが向上するかどうかも判断する必要があります。

稼働時間の保証も重要です。特に、製品が満たすべき SLA と、選択したクラウドサービスがそれらの SLA を満たす可能性があるかどうかを定義する必要があります。一方、災害復旧に関しては、障害発生時にクラウドネイティブシステムをどのように再構築するか、またその場合にどの程度のデータ損失を許容できるかを決定する必要があります。最後に、障害発生時にバックアップ、処理中のキュー、メッセージをどのように処理するかを決定し、イメージを保存する場所とバックアップの有無を決定する必要があります。

最後に、レプリケーションに関しては、システムの中で障害のリスクが高い部分と、障害によって最も影響を受ける部分を特定する必要があります。また、データのコピーが必要かどうか、また信頼性の低いデータのコピーの影響から保護する方法を決定します。

3. セキュリティ

クラウドネイティブデータシステムのセキュリティは、さまざまな側面を持つ非常に広範なトピックです。まず、最も重要なのは、次のことを理解する必要があることです。

データが保存される地域の管轄区域と法律（メトリックとフェイルオーバーデータが保存される国を含む）

ハイブリッドクラウドアプリケーションの場合、クラウドと企業ネットワーク間のリンクをどのように保護するか

連邦のセキュリティ要件を満たすことができますか?

クラウドプロバイダー管理ポータルへのアクセスを制御し、パスワードの変更を処理し、データベースへのアクセスを制限する方法。

クラウドベンダーとオペレーティングシステムのセキュリティアップデートとパッチの取り扱い方

4. 管理性

管理性とは、システムのパフォーマンスと健全性を理解し、操作を管理する能力です。クラウドに関しては、導入と監視という 2 つの原則を考慮する必要があります。

展開に関しては、自問すべき質問がいくつかあります。たとえば、デプロイメントを自動化する方法や、稼働中のシステムを中断せずにパッチを適用または再デプロイメントする方法を検討します。また、デプロイメントが成功したかどうかを確認する方法と、デプロイメントが失敗した場合にロールバックする方法も検討してください。同様に、展開には、必要な環境の数と、それらに必要なストレージと可用性の量を決定することが含まれます。

一方、監視については、アプリケーションをどのように監視するか (既成のサービスを使用するか、ゼロから開発するか)、監視データを物理的にどこに保存するかを計画する必要があります。また、監視計画によって生成されるデータの量と、メトリックログにアクセスする方法を決定する必要があります。同様に、ログデータを失っても大丈夫かどうか、実行時に監視レベルを変更する必要があるかどうかを自問してください。

5. 実現可能性

最後に、実現可能性には、時間と予算の制約内でシステムを維持および提供することが含まれます。この原則に関して考慮すべき点は次のとおりです。

SLA を満たすことができますか?たとえば、顧客に提供する必要がある稼働時間を保証できるクラウドプロバイダーは存在するでしょうか?
クラウドアプリケーションを構築するために必要な社内経験とスキルがありますか? それとも、サードパーティにアウトソーシングする必要がありますか?
メリットとコストのバランスを取り、複雑なクラウドプロバイダーの価格設定を維持しながら、許容できる支出レベルを維持する

6. 優れたクラウドネイティブデータプラットフォームの特徴

これで、クラウドネイティブプラットフォームを作成するときに考慮すべき原則とアーキテクチャ上の考慮事項がわかりました。それでは、優れたプラットフォームが提供すべきその他の機能について見ていきましょう。

1. 費用対効果

確かに、完全に管理されたクラウドサービスとオンプレミス/セルフマネージドサービスのコストには大きな違いがあります。ただし、前者の弾力性と、ほとんどのクラウドプラットフォームが採用している従量課金モデルにより、リソース (およびコスト) を無駄にすることなく、中規模規模で実行することが可能になります。

これは、未使用のリソースに対して追加料金を支払ったり、容量計画に対処したりする必要がないことも意味します。さらに、クラウドプラットフォームのマルチテナントにより、サービスプロバイダーは自社管理型サービスよりもはるかに低いコストでサービスの価格を設定できます。

2. 使った分だけ支払う

前述のように、ほとんどのクラウドプラットフォームは従量課金モデルを採用しており、提供されたリソースに対してではなく、使用したリソースに対してのみ料金を支払います。これらのリソースは、高レベル（API リクエストなど）または低レベル（メモリや CPU 使用量など）のいずれかになります。したがって、ローカルデータの場合とは異なり、使用しない可能性のあるライセンスコアに対して料金を支払う必要はありません。

2. 弾力性と拡張性

優れたクラウドネイティブプラットフォームには、簡単な API 呼び出しやクリックでサービスをスケールアップまたはスケールダウンする機能も含まれています。定義されたポリシーに基づいてプラットフォームがサービスを自動的に拡張できれば、さらに良いでしょう。さらに、事前に管理された容量計画と柔軟なスケーリングにより、スケーラビリティの制限は最も極端な場合にのみ発生します。

4. 可用性

効率的なクラウドネイティブプラットフォームは、高可用性によっても定義され、ほとんどの障害に対処できるように設計されています。たとえば、ほとんどのプラットフォームは少なくとも 99.95% のサービスレベルアグリーメントを提供しており、これは年間のダウンタイムが最大 4.5 時間であることを意味します。しかし、実際には、より高い可用性を要求することもできます。

5. マルチテナント

マルチテナントには、管理性と規模の経済性という 2 つの利点があり、ほとんどのクラウドネイティブサービスがその恩恵を受けています。まず、CPU ではなくクエリやリクエストとしてサービスを提供する S3 などのサービスを使用することで、顧客に最高のユーザーエクスペリエンスを提供できます。すべてのテナントは十分に分離されているため、ユーザーは同じ物理システムが他のテナントにもサービスを提供していることに気づきません。

はい、場合によっては、ユーザーはメモリや CPU などの専用のコンピューティングリソースを購入する必要があります (AWS Aurora の場合がこれに該当します)。ただし、基盤となるインフラストラクチャ (ストレージやネットワークなど) は引き続き共有されます。

6. パフォーマンスの最適化

最後に、さまざまな種類の顧客ワークロードに対応できるようにするには、システムが複数の次元で拡張可能である必要があります。制約は、ハードウェア、オペレーティングシステム、アプリケーションを含むインフラストラクチャ全体で調整および最適化する必要があります。さらに、管理システムの場合、厳密な生産フィードバックメカニズムが必要です。また、システムは、さまざまなスケーラビリティおよびパフォーマンス関連のイベントを分析して学習し、パフォーマンスを最適化するための改善を展開できる必要があります。

オリジナルリンク: https://dzone.com/articles/design-considerations-for-cloud-native-data-system