2019 年に注目すべき 5 つのマイクロサービス トレンド

[[256891]]

2018 年は間違いなく DevOps コミュニティにとって大きな年でした。 Kubernetes は、Cloud Native Computing Foundation (CNCF) を卒業した最初のプロジェクトになりました。 Pivotal は初の株式公開を完了しました。 HashiCorpは19億ドルのユニコーン企業となった。 VMware は Heptio を約 6 億ドルで買収しました。この一連の出来事の出現により、DevOps の波の重要性が改めて強調されました。

昨年 1 月、サービス メッシュ、イベント駆動型アーキテクチャ、コンテナ ネイティブ セキュリティ、GraphQL、カオス エンジニアリングなどのトピックを網羅したマイクロサービス開発のトレンド予測を発表しました。これらのテクノロジーの人気が高まっている一方で、翌年には他の新たなトレンドも見られました。1) テストの自動化。 2) 継続的デプロイメント/検証（CD/CV） 3) インシデント対応4) クラウドサービスコスト管理（CSEM） 5) 機械学習 (ML) などの Kubernetes 拡張機能

1. テスト自動化の台頭

従来、テスト ケースは、さまざまな状況下でソフトウェアが正しく実行できるかどうかを判断するために個人によって設計されていました。通常、品質保証 (QA) エンジニアがこのようなテスト ケースの作成と実行を担当します。しかし現在では、テスト駆動開発の台頭により、ソフトウェア エンジニアが徐々に従来の QA チームのテスト責任を引き継ぐようになっています。言い換えれば、開発者は全体的な継続的インテグレーション (CI) プロセスの一部としてテストを実行し始めました。テストによって開発者に新たな負担がかかり、生産性が低下することは明らかです。

企業には、自動的に設計、実行、結果を報告できるソフトウェア テスト ソリューションが必要であると私たちは考えています。このようなソリューションでは、継続的インテグレーション システムに接続し、新しいコードをリアルタイムでチェックし、人間のエンジニアが行うのと同様のコメントを追加することで、摩擦のない介入を可能にする必要があります。さらに、私たちの観察によれば、このようなテスト ソリューションは、エンジニアが UI を通じて問題を見つけ、レポートを見逃す可能性を減らすことができるように、ユーザー インターフェイス (UI) を通じてテストする必要もあります。

ソフトウェア テストの自動化を実装すると、バグの修正に必要なリソースを削減できます。自動化されたソフトウェアがエラーを識別すると、そのエラーの修正を自動的に生成できます。単純なバグは自動パッチで修正できますが、複雑なバグは手動で設計されたテンプレートや「例外ベースの修復」 (問題が解決するまでコードに小さな変更を加える修復メカニズム) を使用して対処できます。さらに、推奨エンジンは、以前のエンジニアの修正データを使用してトレーニングされ、事前テストされて、人間による承認前にスマートな提案を提供することができます。

私たちは、ソフトウェア テストが人工知能技術の重要な応用方向であるべきであり、業界の生産性、コスト、カバレッジ、精度を大幅に向上させるのに役立つと考えています。当社は以前、機械学習を活用したソフトウェア テスト ソリューションに対する期待を表明しており、この市場は規模が大きく (約 32 億ドル相当)、成熟しつつあると引き続き考えています。

2. 継続的な導入/検証による生産性の向上

企業は、ソフトウェアのリリース サイクル要件の加速化によるプレッシャーを感じ続けるでしょう。継続的デプロイメント (CD) を使用すると、テスト済みのコードを本番環境に自動的にデプロイできます。継続的デリバリーは、コードが本番環境に迅速かつ安全にデプロイされることを保証するために使用される一連の設計プラクティスですが、継続的デプロイメントは、デプロイメントに関連する管理タスクのみに焦点を当て、次のステップのための強固な基盤を提供することを目指しています。

継続的デプロイメントは、DevOps エンジニアの手動操作に取って代わります。私たちの理解によれば、一部の金融機関では、DevOps 従業員の 10 人に 1 人が本番環境へのソフトウェア導入タスクを担当しています。継続的デプロイメント ソフトウェアによってこれらの面倒な作業が軽減されると仮定すると、世界中の DevOps 従業員の価値が 10% 増加することになります。この市場の総規模は20億ドル近くになると考えています。

継続的検証 (略して CV) は、継続的デプロイメントの上にさらにインテリジェンスのレイヤーを追加します。継続的な検証では、ログと APM からイベント データを収集し、機械学習技術を適用して、デプロイメントの成功と失敗につながる要因を理解します。継続的な検証には人間が関与するコンポーネントが必要であり、エンジニアがフィードバックを提供してモデルの精度を向上させながら、徐々にシステムへの信頼を構築できるようにします。継続的な検証により、失敗したデプロイメントを安全にロールバックできるようになります。今後の継続的検証ソリューションは、継続的デプロイメントがマルチクラウド環境内のインテリジェントな制御ポイントとなり、予測機能を提供し、クラウド、リージョン、構成に関する最適な洞察を提供し、特定の特性に基づいてデプロイメント サービスの調整を実装するのに役立つと考えています。

継続的デプロイメント ソリューションは数多くありますが、最も人気のある 14 のソリューションを下の図に示します。これには、クローズド ソースおよびオープン ソース プロジェクト、およびパブリック クラウド サービス プロバイダーによって提供されるホスト型サービスが含まれます。この分野で最も有名なソリューションは、GitHub で 5,600 を超えるスターを獲得したオープンソース プロジェクトである Spinnaker です。

3. 修復的インシデント対応

サイト信頼性エンジニア (SRE) は、回復力の面で真の課題に直面する複雑な分散システムの応答性を管理する責任を負います。 Google が発行した書籍「Site Reliability Engineering」によると、サイト信頼性エンジニアは、以前はシステム管理者が手動で実行していたプロセスを自動化する責任を負っています。彼らは、「サービスの可用性、待ち時間、パフォーマンス、効率、変更管理、監視、緊急対応、容量計画」に関するソリューションを確立する責任を負っています。当然のことながら、緊急時/インシデント対応もサイト信頼性エンジニアの重要なタスクの 1 つです。

ダウンタイムは重大な経済的影響を及ぼすイベントであるため、より迅速な問題解決が重要になります。 Gartner は、ダウンタイムによる収益損失は 1 分あたり平均 56,000 ドルになると推定しています。 Amazon のような大規模なネットワーク資産保有者にとって、ダウンタイム 1 分ごとに 22 万ドルの損失が発生する可能性があります。サービスが停止するたびに、企業は莫大な経済的損失を被り、ブランドイメージに深刻な影響を及ぼします。

サービスに障害が発生すると、さまざまな機能的役割を持つ対応チーム (インシデント コマンダーを含む) がアラートを受信し、一連のワークフローがトリガーされます。インシデント指揮官は、インシデントの内容、その進行状況、およびそれを解決するために行われた作業を説明する「インシデント ステータス ファイル」を管理する責任があります。各チームメンバーは、事前に定義されたテンプレート化された手順に照らして問題解決プロセスを実行することが求められます。問題が解決したら、チームは事後検証にも参加してインシデントを理解し、可能であれば再発を防ぐ必要があります。 Google は、チームが「インシデント自体、関連する影響、インシデントを軽減または解決するために実行されたアクション、インシデントの根本原因、インシデントの再発防止に役立つインシデント後のアクション」を記録することを推奨しています。これは、重要なフォローアップ ガイダンス資料になります。

サイト信頼性エンジニアリング チームがインシデント対応に PagerDuty、Slack、Jira、Google ドキュメント、ナレッジ ベースを使用しているとよく聞きます。私たちは、これらの正確なソリューションをエンドツーエンドの SaaS プラットフォームに結び付けることで、自動化された修復アクションをサポートし、ベスト プラクティス ガイダンスを実装できると考えています。統合プラットフォームにより、平均復旧時間 (MTTR)、コラボレーション、知識共有も加速します。

最新のインシデント対応機能を提供する 5 つのソリューションを特定しました。これらの集中型プラットフォームは、機能的役割を細分化してワークフローを開始するだけでなく、インシデントの潜在的な影響、現在のステータス、イベントのタイムライン、および時間の経過に伴う結果を示す必要があります。私たちは、これらのプラットフォームが、レジリエンス テストのベスト プラクティスであるカオス エンジニアリングを強力に補完できると考えています。将来的には、これらのプラットフォームは、Gremlin などのカオス エンジニアリング ソリューションにイベント情報を送り、どのサービスを予防的にテストする必要があるかを通知することも可能になります。このようなプラットフォームの継続的な改善により、バックエンドの回復力のレベルが大幅に向上し、最終的には運用エンジニアがより安心して夜間を過ごせるようになるでしょう。

4. クラウドサービス経費管理（CSEM）はコスト削減に役立ちます

今日、パブリック クラウドのコスト管理は、エンジニアリング チームや IT チームに大きな影響を与えるだけでなく、会社全体で高い注目を集める数少ない課題の 1 つになっています。現在、ほとんどの企業はハイブリッド クラウド アプローチを採用していますが、純粋なパブリック クラウド ソリューションを使用する顧客の数は急速に増加しています。ガートナーの統計によると、IaaS と PaaS の世界収益は、2018 年の 462 億米ドルから 2018 年には 907 億米ドルに増加し、年間平均複合成長率は 25% になると予想されています。 Rightscale が発表したレポートでは、調査対象となった 997 人の IT プロフェッショナルのうち、92% がパブリック クラウドを使用しており、81% がマルチクラウド戦略を使用していることも指摘されています。実際、パブリック クラウドは、セキュリティと可用性の向上、運用とパブリック リソースにかかる支出とコストの削減など、一連の重要なメリットをもたらします。パブリック クラウドの人気が高まり、導入が急速に進むにつれて、コスト管理と予測機能の重要性はさらに高まると考えられます。

クラウド コスト管理は、さまざまな理由により困難な作業です。多くのチームがパブリッククラウド サービスを使い始めていますが、監視メカニズムがまだ追いついていないため、クラウド ソリューションは強制的に一種のシャドー IT 製品になってしまいました。このガバナンスの欠如は、サービスの無秩序な拡大につながる可能性があります。上司からの「迅速に行動」というプレッシャーやパフォーマンス要件に直面して、開発者は個人評価プロセスにおけるコストの問題を無視する可能性があります。サービスの幅広さと頻繁な価格変更により、クラウド支出を追跡することは非常に困難になります。クラウド請求書には 10 億を超える経費明細が含まれるものもあり、平均的な企業がそれを正確に解析するのはほぼ不可能です。こうした一連の課題に直面して、ガートナーは「2020 年までに 80% の組織がクラウド IaaS 予算を超える」と結論付けました。

下の図では、パブリック クラウドとサードパーティ サービスを代表する 18 のクラウド サービス コスト管理ソリューション オプションを分類しています。その中で、VMwareは、2018年8月にこの仮想大手の5億ドルの買収提案を受け入れたCloudHealthを買収した。Azureは2018年に5000万ドルから7000万ドルでCloudynを買収し、製品名をAzure Cost Managementに変更した。 2019年1月初旬、Amazonは製品ポートフォリオを充実させるためにTSO Logicを買収しました。 2018 年、Forrester は「クラウド コストの監視と最適化」と題したレポートを発表し、VMware CloudHealth と Rightscale が先頭に立つ 9 つの主要ベンダーを分析しました。

クラウドコスト管理ソリューションはすでに多数存在しますが、コスト管理は解決が難しい問題のままです。運用担当者からは、クラウド経費管理ツールはプラットフォーム間で結果を標準化し、クラウド リソースを特定の所有者とチームにマッピングして、財務部門が支出を特定の製品または事業部門に一致させることができるようにする必要がある、という苦情がよく寄せられます。ガートナーは、この効果的な管理機能がなければ、クラウド サービスの全体的な利用率は長期間にわたって 35% を下回る可能性が高いと述べています。さらに、このようなソリューションでは、過剰にプロビジョニングされたリソースや慢性的にアイドル状態のリソースを特定するクラウド サービス コスト管理ツールなど、最適化の領域も特定する必要があります。ソフトウェアは、予約インスタンスとスポットインスタンス、継続的なインスタンスのサイズ変更、チャージバック、カスタム割引の設定機能、異常な支出のフラグ付けなどをサポートする必要があります。さらに、トラフィックの増加、データ ストレージ要件、サービス利用率に基づいて、特定の期間にわたる支出レベルを予測する必要があります。パブリック クラウド リソースの使用が拡大するにつれて、コスト管理と予測の重要性も高まると予想されます。

5. 機械学習のためのKubernetes拡張機能

Kubernetes は DevOps の世界に旋風を巻き起こし、コンテナのオーケストレーション ソリューションとして定着しました。その適用範囲は拡大し続けており、機械学習プラットフォーム スタックの不可欠な部分になると期待されています。たとえば、Google はオープンソースの Kuberflow をリリースしました。これは、カスタム リソース定義 (CRD) をクラスターに追加して Kubernetes API を拡張し、機械学習ワークロードの実行優先度を高めます。 KubeCon Seattle 2018 カンファレンスでは、Kubeflow が最も注目されたクラウド ネイティブ プロジェクトの 1 つになりました。実際、これを研究しているのは Google だけではありません。 Lyft も Kubernetes を使用して独自の機械学習プラットフォームを構築しています。他のユニコーン企業も、機械学習や分析ワークロードの処理プラットフォームとして Kubernetes を標準化しようとしていると聞いています。

来年の今頃も、テスト自動化、継続的デプロイメント/継続的検証、インシデント対応、クラウド サービスのコスト管理、機械学習向け Kubernetes の拡張などのトピックに引き続き注力していきます。あなたやあなたの友人がオープンソース プロジェクトやこれらの分野を探求しているスタートアップで働いている場合は、あなた自身の経験に基づいた意見を共有していただければ幸いです。最後に、私たちが言及しなかった重要な点や、上記の問題に対する皆さんの異なる視点など、皆さんのコメントを拝見できることを楽しみにしています。読んでくれてありがとう！

オリジナルリンク: https://medium.com/memory-leak/5-microservices-trends-to-watch-in-2019-fd2dbd33780d