クラウドネイティブ インフラストラクチャによくある10の課題

Cloud Native Computing Foundation (CNCF)によると、クラウドネイティブアーキテクチャーの採用は現在も拡大しており、クラウドネイティブ開発者は680万人を超えるそうです。これにはコンテナオーケストレーションツール、サーバーレスプラットフォーム、またはその両方を使用している組織のエンジニアが含まれます。チームがKubernetesに移行する場合も、複数のクラウドをデプロイする場合も、ハイブリッドクラウドの設計を使用する場合も、クラウドネイティブインフラストラクチャは大きなメリットをもたらしますが、同時に複数の問題をもたらします。

クラウドベースのインフラストラクチャへの移行を検討していますか？このブログでは、クラウドネイティブアーキテクチャーで気を付けるべき最もよくある課題について説明します。

1. 従量課金制の価格モデルにより過剰なコストが発生する可能性がある

クラウドネイティブインフラストラクチャの場合には、物理サーバや仮想サーバを購入する場合と価格モデルが異なります。クラウドネイティブアーキテクチャーには追加の費用がかかるため、従量課金制の価格モデルでコストを適切に管理する必要があります。コストは変動し、使用量に比例します。

オンプレミスでのデプロイメントと、Amazon EC2インスタンスなどの従来型のマイグレーション・アーキテクチャーでは、物理マシンや仮想マシンなどの段階的なサンクコスト（埋没費用）が発生します。モダナイズの1つの選択肢は、ここにサーバーレス関数を代わりに採用することです。しかし、個々のサーバーレス関数を適切に定義しないと、クラウドネイティブアーキテクチャーのコストが高くなる可能性があります。高メモリ、高い同時実行性、長時間実行の関数は、スケールアウトするように設計されている場合、コストが指数関数的に増加する可能性があります。追加のコストを回避するために、クラウドネイティブインフラストラクチャにおいて、非効率なクラウドリソースを特定することが重要です。

2. 柔軟な環境であるがために、過去に遡ることが難しい

オンプレミスまたはホスティングされたインスタンスでは、設計された固定のリソースプールがあります。一方で、クラウドネイティブマイクロサービスは通常はオンデマンドで、規模も期間も柔軟で、多くの場合はステートレスで、必要な間だけ存在する短期的な性質があります。そのため調査において、マイクロサービスがすでに存在しない、または状態が変化してしまうことにより、過去のある時点でどのような問題が起こったのかを判断することは困難です。

New Relicを使用すると、テレメトリーを経時的に確認し、それをユーザーからの苦情、イベント通知、またはパフォーマンスの異常と関連付けることができます。デプロイメントを記録・モニターし、それをデプロイメントマーカーで追跡することができるため、それらをアプリケーションのパフォーマンスと関連付けることができます。

3. インフラストラクチャについてのインサイトが乏しい

クラウドネイティブインフラに移行する際、大きな課題となるのは、単純にインサイトがないことです。基盤となるインフラで何が起こっているのかがわからないのです。

どのサービスが原因なのかを判断し、管理者権限の及ばないところに存在するクラウドベースのインフラに問題があるのかどうかを特定できるようなオブザーバビリティソリューションが必要です。

クラウドベンダーはモニタリングサービスを提供しており、New Relicはそれらのサービス全体を可視化することができます。それによって、システム全体を見渡しながら、どのような問題が発生しているのかを判断することができます。New Relicを使用すれば、Amazon Web Services (AWS)、Microsoft Azure、およびGoogle Cloud 向けのインテグレーションを設定することができます。

4. セキュリティはますます重要で難しくなる

前の課題で説明した可視性の欠如は、セキュリティに関してはさらに問題になります。すべてを把握するのは難しいため、重要なセキュリティリスクを見落とす可能性があります。分析するセキュリティデータが多いと、調査費用が高額になります。クラウドネイティブなインフラストラクチャでは、どのデータが適切かを判断する必要があります。

多くのツールとマルチクラウド環境およびハイブリッドクラウド環境があることから、一貫したポリシーを実施することは困難です。適切に設定されていないクラウドインフラストラクチャは攻撃のリスクにさらされます。これらすべてに迅速な対応が必要です。

New Relicを使用すれば、クラウドプロバイダーのセキュリティサービスと統合することができます。AWS CloudTrailなどのインテグレーションをご確認ください。サイロや追加の設定にうんざりしている場合には、New Relic脆弱性管理を使用することで、オブザーバビリティとセキュリティをすべて一か所で実現することができます。

5. 開発サイクルとリリースサイクルの増加には連携が必要

クラウドネイティブなインフラストラクチャでは、より頻繁なデプロイメントサイクルと継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインに対処することになります。組織は、エンジニアリングチームが部門横断型のチームを利用して連携できるようにDevOpsプラクティスを構築してきましたが、開発者は、解決を先延ばしにすることで厄介かつ高額になる前に問題を突き止める必要があるため、「シフトレフト」の傾向が顕著になっています。

より頻繁にデプロイするためには、安定性を確保する必要があります。デプロイメントを追跡して、アプリケーションのパフォーマンスに関連付けた方がいいかもしれません。ここで、デプロイメントマーカーを使用すると、デプロイメントに関連する問題がいつ発生したかを確認し、原因と結果を理解することができます。

New Relicを使用すれば、アプリケーションパフォーマンスモニタリング（APM）のチャートでこれらのデプロイメントマーカーを確認することができます。New RelicがCI/CDパイプラインを支援できるその他の方法として、すでに使用しているCI/CDツールとのインテグレーションや、CodeStreamを使ってIDEで問題を可視化し、チーム間の連携を高めることが挙げられます。

6. 複数のシステム、複数のクラウドを管理・監視する必要がある

静的なシステム、さらには仮想マシンでは、新しいシステムを追加するためのプロセスや承認がたくさんありますが、クラウドネイティブ環境では、1行のコードだけで追加することができます。リソースやサービスの急速な普及によるこれらすべての変化の管理・モニターは、非常に困難な場合があります。

このような無秩序な環境にもかかわらず、エンジニアリングチームは、アプリケーションが複数のクラウド環境、物理マシン、仮想マシン、コンテナ、コンテナ化されたステートフルワークロード、オーケストレーションエンジン、サーバーレスプラットフォームにまたがっていても、アプリケーションの可用性、パフォーマンス、およびセキュリティを維持する必要があります。

特定の1つのクラウドベンダーの使用に縛られることなく、これらのすべてのシステムとクラウドを可視化する必要があります。すべてを一か所で確認することができ、尚且つ、使用している他のツールと統合することができるオブザーバビリティプラットフォームは、混乱を乗り越えるのに役立ちます。

7. システム構成の設定を管理するのは難しい

理想的にはInfrastructure as Codeの信頼できる唯一の情報源は1つですが、実際には一元的に管理できない、またはコードで実装できない設定もあります。また、アプリケーションオーナーやシステムオペレーターがデプロイメントパイプライン外で局所的な変更を行うため、システム構成が時間とともにずれていくことがあります。

そのようなずれが一度発生すると、誰もが理解できる予測可能な環境ではなくなります。クラウドネイティブなインフラストラクチャの場合と同様に、設定のずれは複雑になるにつれて増加します。

New Relicを使用すれば、異常または予測不能な方法で動作している具体的なコンポーネント、サービスまたは構成を特定することができます。データを素早く使用して、実際の動作とそれが意図された動作とどのように異なるかを判断することができます。

8. 幅広い柔軟性に対処し、分析麻痺（考えすぎの状態）を克服する必要がある

選択肢が多い場合には、適切な選択を見極めることが重要です。クラウドネイティブ環境のすべての部分をモニターすることは、たくさんのデータを収集できることを意味します。しかし、どうすれば行き詰まることなく、それを意味あるものとすることができるでしょうか？

選択肢を比較し、最善の行動を取るために最適化できるオブザーバビリティプラットフォームが必要です。様々なクラウドサービス間のコストパフォーマンスと、環境の規模をどのように適正化するかを検討します。適切なデータがあれば、実験して早く失敗し、素早く次に進むことができます。New Relicを使用すれば、すべてのインフラストラクチャを一か所で詳細に可視化できます。

たとえば、ダッシュボードを手動で調べて問題がなぜ発生するのか、また問題が何に影響を与えるのかを理解する代わりに、すべてのインシデントの根本原因を突き止めることができます。

9. 高い信頼性をもたせるには時間がかかる

クラウド内でも、信頼性の問題を回避するために、クラウド機能を正しく利用するためのアーキテクチャーが必要です。グループによっては複数の地域を使用する場合があり、信頼性を実現するのは困難でコストもかかります。

クラウド内では、信頼性へのオブザーバビリティを実現したいはずです。そうすれば、アップタイムやページロード時間の遅さなどの全体的なパフォーマンス指標を観察でき、自社のアプローチが成功しているかどうかを確認することができます。フロントエンドのユーザーエクスペリエンスからバックエンドのインフラまで、すべてのプロセスで信頼性を監視できるようにする必要があるのです。

信頼性には様々な形式があります。リスクがどこに潜んでいるか分からないことが多くあります。そのため、高可用性アーキテクチャーについては、時間をかけて観察しないと判断できません。

信頼性がどこで成果を上げているかを確認するには、オブザーバビリティツールが必要です。New Relicを使用して信頼性に関する決定に大きな影響を与える方法をご覧ください。

10. 組織的な変化と適切なスキルを備えたチームの両方が必要

組織は、クラウドネイティブなインフラストラクチャの使用に移行するにつれて、課題5で説明したように、チームのDevOpsプロセスと文化をCI/CDパイプラインに反映させる必要があることに気付きます。しかし、チームの文化を変化させる際に、新たなスキルも必要となります。

クラウドネイティブ環境で障害が発生した場合は、全員の助けが必要です。チームはクラウドアーキテクトに求められるスキルを身につける必要があります。専門知識には、マイクロサービスベースのアプリケーション、コンテナベースおよびKubernetesベースのアプリケーション、そしてパブリッククラウドプロバイダーのサービスを活用するアプリケーションの設計・構築が含まれます。

クラウドネイティブなアーキテクチャーに必要な文化の変化は、当然ながらオブザーバビリティの文化に合致します。微小な障害が予想され、それを迅速に軽減するためには、運用チームと開発チームの全員にオブザーバビリティが必要です。開発エンジニアも運用エンジニアも、Apdex、平均応答時間、エラー率、スループットなどのメトリクスを気にしています。

オブザーバビリティを備えることで、これらの障害に素早く対処できます。そして、より機敏になる自由を手に入れられます。