WOT サミットの全記録: DevOps の道には何千人もの人々がさまざまな顔を持っている

2018年5月18日、51CTO主催のグローバルソフトウェアおよび運用技術サミットが北京で開催されました。世界各国の企業の技術エリートが北京に集まり、最先端のソフトウェア技術について議論し、運用・保守技術の新たな限界を探りました。このカンファレンスでは、スターが勢ぞろいしたメインフォーラムに加えて、コンテナ、AI、ブロックチェーン、ビッグデータ、モノのインターネット、DevOpsなど、最も人気のある技術応用分野に焦点を当てた12のサブフォーラムがそれぞれ独自の特徴を持っています。参加者にとって、技術的なインスピレーションを見つけ、先駆者の経験から学ぶのに最適な場所です。

デジタル変革の時代において、企業は一方では生産・管理能力を向上させる方法を見つけ、他方では独自の IT 能力を開発する必要があります。この方法でのみ、企業は IT の力を最大限に活用してビジネスを展開し、IT の考え方を使用してビジネス変革を促進することができます。企業にとって、関連するソフトウェア アプリケーションの開発と運用および保守は、この IT 能力の最も重要な現れです。

実際の企業環境では、新しいテクノロジーや新しいビジネス モデルが継続的に出現するため、アプリケーションの開発と運用および保守には、かなりの期間にわたる継続的な反復と配信が必要になることがよくあります。明らかに、このビジネス モデルは、会社の IT チームと能力にとって大きな課題となります。こうした課題の背後には、マルチクラウド環境、コンテナ技術、人工知能などの技術の発展もこの傾向を後押ししています。いかなる企業にとっても、開発と運用のマラソン戦争に勝つことは容易なことではありません。

今回のWOTサミットでは、現在企業が懸念しているDevOpsの課題に対応するため、「DevOps変革への道」というサブフォーラムを特別に設置し、特別な議論を行っています。このサブフォーラムでは、51CTOがeBay中国R&DセンターのテクニカルディレクターのRu Bingsheng氏、ThoughtWorksのシニア品質コンサルタントのQin Wuyi氏、IBMハイブリッドクラウドのテクニカルマネージャーのPan Xuemei氏、CMBクラウド金融PaaS研究センターのディレクターのChen Shake氏など、業界のリーダーたちを招き、DevOpsコンセプトの発展、進化、応用、未来について、さまざまな視点と次元から解釈しました。

CMB CloudのPaaSコンテナ実装の実践

効率性とコストは、企業が多くの作業を行う際に最初に考慮する 2 つの主要な問題であり、これは多くの企業がクラウドに移行する際に考慮する必要がある重要なポイントでもあります。クラウド コンピューティングに代表される概念自体は、企業の IT の効率とコストを大幅に改善することができますが、クラウド アーキテクチャが準備されているという前提の下では、企業が効率とコストの道を歩むにはまだ長い道のりがあり、導入する必要のある新しいテクノロジやアプリケーションが数多くあります。

従来の PaaS プラットフォームでは、仮想マシン自体がコンピューティング、ストレージ、メモリなどのシステム リソースを大量に占有する必要があります。この問題を解決するには、コンテナ技術の活用が不可欠です。 CMB Cloud は、コンテナ プラットフォーム アーキテクチャとして、現在非常に人気のある OpenShift プラットフォームを選択しました。 OpenShift は現在利用可能なコンテナ プラットフォームの中で最も成熟度が高く安定したものの 1 つであり、企業が真の DevOps を実現できるようにするための一連の CI/CD ツールを提供します。

CMBクラウド金融PaaS研究センター所長の陳シェイク氏は次のように述べた。「まず、効率性の観点から言えば、コンテナはインフラストラクチャのさまざまなリソースを非常に効率的に活用できます。 CMB Cloud の金融業界での経験に基づくと、過去には開発環境を展開するために数百の仮想マシン リソースが必要だった可能性があります。しかし、コンテナ技術を使用すると、開発環境全体の構築を完了するために必要な仮想マシンは 12 台だけです。このコスト上の利点は依然として非常に大きいです。 OpenShift プラットフォームの実際の運用と保守では、Kubernetes の年 4 回の頻繁な更新に直面していますが、OpenShift は更新速度に対応できるだけでなく、提供する完全なサービスにより、企業が新しいバージョンをより適切に展開して使用するのに役立ちます。

基本的なコンテナ プラットフォームが整備されたら、CMB Cloud が行う必要があるのは、完全な DevOps 開発ツール チェーンを構築することです。まず、CMB Cloud Innovationでは、現在比較的良好なパフォーマンスを発揮しているRedmineを活用して、統一された共同管理を実現します。このコラボレーション システムには、需要、計画、開発、テスト、展開、運用、保守などのモジュールが含まれています。

開発プロセス中、Gitlab 分散コード リポジトリは開発中のさまざまな種類のコードを効率的に管理できます。 SonarQube は、コードの標準化された検出を便利かつ自動的に実行し、潜在的な脆弱性をスキャンできます。 ***、CMB Cloud は Jenkins を使用してアプリケーションを構築し、Testlink を使用してテスト プロセスを管理します。もちろん、これらのツールにはすべて関連するプラグインが用意されているため、管理者は Redmine を使用して開発とテストのプロセス全体を管理できます。これは、DevOps を実装するプロセスで CMB Cloud が使用するアーキテクチャ全体です。

このような最新のコンテナ プラットフォームと、その上で実行される DevOps プロセスとツールの全体セットに関して、陳シェイク氏は中国招商銀行の田慧宇頭取の言葉を引用して次のように要約しています。「景気低迷という循環的要因も、金利と為替レート改革という市場要因も、負債削減と強力な監督という政策要因も、銀行のビジネス モデルを変えるには不十分です。」銀行のビジネスモデルを根本的に変え、覆すことができるのはテクノロジーだけです。

マルチクラウド環境におけるDevOpsと運用・保守管理の実践

クラウドとコンテナの実践は、多くの企業が行っている、または行ったことがあるものです。クラウドコンピューティングの将来においては、マルチクラウド環境は避けられません。マルチクラウド環境では、DevOps ツールチェーンの構築と展開は単一のクラウド環境よりも明らかに複雑になり、セキュリティ上のリスクも高まります。このような問題に直面したとき、世界をリードする技術革新企業である IBM には、明らかに活用できる経験がもっとある。

この点について、IBMハイブリッドクラウドのテクニカルマネージャーであるパン・シュエメイ氏は次のように述べています。「パブリッククラウド、プライベートクラウド、IBMクラウドサービスで構成されるマルチクラウド環境において、最も重要なDevOpsツールチェーンとしてIBMが推奨するのは、Slack、Trello、Github、Jenkins、JMeter、Terraform、UrbanCode Deployです。」これらは、DevOps プロセスにおけるコラボレーション、コード管理、アプリケーションの構築、テスト、コンテナの展開などのプロセスに対応します。

コンテナ環境の中核として、IBM の DevOps ソリューション全体は IBM Cloud Private コンテナ クラウド プラットフォームを中心に構築されます。このクラウド プラットフォームは、マルチクラウド環境でのコンテナ管理およびオーケストレーション機能を提供します。このプラットフォームは、Kubernetes、Cloud Foundry、VMware、AWS などの複数のプラットフォームと互換性があり、ユーザーに自由な選択の余地を残します。

さらに、IBM の統合ソリューションを使用すると、DevOps 全体をグラフィカル インターフェースで自動的に提供できます。この機能の中心となるのは、IBM Cloud Automation Manager 管理ツールです。この管理ツール セットは、現在普及しているさまざまな DevOps ツール用のインターフェイスを提供し、統一されたグラフィカル インターフェイスの下で完全な管理機能を実装できます。

***、最も重要なデプロイメント リンクでは、IBM には専用の Urban Code Deploy ツールもあります。このツールは、複数のクラウド プラットフォーム上でアプリケーションとマイクロサービスの自動化されたプロセス指向の展開を実現し、フォールト トレランスと展開品質を管理および監視できます。

もちろん、IBM には DevOps プロセスの他の側面を提供するための関連するツール チェーンとエクスペリエンスも多数あります。たとえば、障害管理ツール チェーン、マルチレベル イベント相関分析、サービス管理と運用保守のリファレンス アーキテクチャ、運用保守変革における組織変更リファレンス、運用保守における革新的なワークフローと方法などです。

IBM が提供する完全な DevOps ソリューションにより、企業はより高い効率とより低いリスクで DevOps を実装できます。

継続的インテグレーションの実践と重要性

DevOps の中核リンクの 1 つとして、継続的インテグレーションは企業開発にとって非常に重要です。これにより、同社の開発部門は、高品質のアプリケーションを継続的に生産しながら、全体的に高い効率を維持できるようになります。これを実現するには、適切なツールに加えて、高度な管理とプロセスも必要です。そうでなければ、いわゆる継続的インテグレーションや DevOps は単なる空虚な見せかけに過ぎなくなります。

この点に関しては、ThoughtWorks のシニア品質コンサルタントである Qin Wuyi 氏が豊富な経験を持っています。今回のDevOps特別セッションでも、航空会社の事例を交えながら、CI全体、さらにはDevOpsにおけるプロセスとマネジメントの価値と重要性について深く解説していただきました。

一般的に、英語の「CI」は一連のツール セットを表し、中国語の「継続的インテグレーション」は、これらのツール セットの背後にある企業開発が達成したいレベルを表します。

Qin Wuyi 氏は、ある航空会社の CI の事例について次のように述べています。「この航空会社は 4 年前に ThoughtWorks の CI ツールセットとソリューションを使用しました。」現在、当社には 7 つのフルスタックグループに分かれた 50 名の開発チームと、QA 品質管理の 9 名からなるチームがあります。全体的な開発アーキテクチャでは ASP.Net を使用します。

同社は DevOps プロセス全体に対応する包括的なソリューションを提供しています。コードの構築には Git が使用され、ユニットテストには Nunit と .Net Foundation が使用されます。 CI/CD プラットフォームには、ThoughtWorks が開発した GoCD 継続的インテグレーション プラットフォームが使用されました。 *** 同社には、SmokeTest、QA Deploy、E2E テスト、パフォーマンス テスト、バックエンドの Sonar コード検出および分析ツールなどの完全なテスト リンクもあります。

この規模のチームとさまざまな自動化ツールの支援により、同社の開発部門は 1 日に 30 回以上コードを送信し、ユニット テストのカバレッジは 96% を超え、Selenium Test に基づくエンドツーエンドの自動テスト プロジェクトは 200 件を超えています。すべての指標データは非常に正確です。

しかし、そのようなチームの場合、CI モニター上のコードの CI ステータスは常に赤色の警告状態となり、アプリケーションの配信は非常に遅くなります。主な原因は、コードの提出とテストのプロセスにおける不規則性です。開発者が提出したコードがテストに合格できない、開発者の設定が間違っている、テストと開発が同期していない、開発者が独自に行動するなど、さまざまな現象がチーム内で同時に発生します。 *** の外見の下には、チーム全体の非効率的な運営があります。

この点に関して、秦無怡はチームに加わった後、一連の改善提案を行った。

1. 毎日コードを送信する

2. ビルドできないコードは提出しない

3. 統合に失敗したビルドをすぐに修正する

4. 自動テストを書く

5. 提出されたすべてのコードはすべてのテストとレビューに合格する必要があります

6. 提出前にプライベートビルドを実行する

7. ビルドできないコードはチェックアウトしない

これらの原則と、これらの原則に基づいた一連の特定のプロセス改訂に従って、利用可能なビジネス アプリケーションの各バージョンに対する会社の平均労働時間は 180 時間から 55 時間に短縮されました。コストを増やすことなく、全体的な効率が 3 倍に向上しました。効果はすぐに現れました。

このことから、CI プロセスで使用されるさまざまなソフトウェアは単なるツールであることがわかります。ツールがすでに導入されている場合、作業プロセスを改善し、協力とルールと規制を強化することが、チームが DevOps を実現するための中核的な要素となります。

自動テストにおけるデータ準備

テストは、コード、ビルド、さらにはアプリケーションが利用可能で効果的であることを確認するための重要なステップです。また、アプリケーションが利用可能であることを確認するために必要なステップでもあります。したがって、効果的なテストを確保することが、DevOps を効果的にするための重要なリンクになります。

しかし、ほとんどのインターネット企業では、複雑なビジネス、多数のユーザー、長いビジネス プロセスにより、アプリケーションのリリース前のテストが非常に複雑になります。これらのうち、データの準備が最も重要です。この点について、eBay 中国 R&D センターのテスト インフラストラクチャのテクニカル ディレクターである Ru Bingsheng 氏は、次のように述べています。「eBay の経験によると、CI の失敗の 30% は、コードやビルド自体の問題が原因ではありません。」本当の問題は、テストデータの準備と使用にあります。ビジネス、データ構造などの変化により、テストに必要なデータは頻繁に変更されます。テスト データの準備で変更に対応する変更が行われない場合、CI テスト全体が失敗します。したがって、テストデータの準備が非常に重要になります。 eBay のような多国籍電子商取引プラットフォームの場合、ユーザー、言語、商品、法律や規制、物流、支払い方法など、さまざまな違いがあるため、テスト データの準備自体が非常に複雑なプロセスになります。

初期の段階では、eBay は Java ベースのデータ ツールを使用して、ターゲットを絞った方法でテスト データを生成していました。この方法では、さまざまなテスターが独自のテストに必要なデータをカスタマイズできますが、操作がかなり面倒で扱いにくい方法です。そのため、eBay のテスト データ生成は、後に 2.0 時代、つまり機能ベースのテスト データ生成に移行しました。現時点では、さまざまなタイプや要件に応じてデータをバッチで迅速に生成できます。これにより、テスターの運用上のプレッシャーと時間コストが大幅に軽減されますが、まだ十分に自動化されていません。最終的に、eBay のテスト データ生成は 3.0 段階に入りました。テスト データ生成はマイクロサービスになり、テスト プロセスではこのサービスを呼び出すだけで済みました。プロセス全体が効率化され、自動化されました。このマイクロサービスも専任の開発者によって更新および保守されていました。

データ準備は自動テストのほんの一部に過ぎず、DevOps 全体の中ではごくわずかな割合を占めるにすぎません。しかし、eBay のようなインターネット企業にとって、自動テスト データ生成は明らかに、eBay のグローバル DevOps を実現するための前提と基盤を提供できます。

DevOpsの旅

DevOps はあらゆる企業にとって大きなチャンスであると言えます。これは、企業のビジネスとアプリケーション、企業の IT への投資と構築、そしてさらに重要なことに、企業の IT チームの管理と開発の考え方に関連しています。 DevOps は、企業の IT 開発チームの精神的な中核に例えることもできます。 DevOps の重要性はいくら強調してもし過ぎることはありません。

DevOps の広大な概念の下では、企業はアーキテクチャとツールに対応する革新を行うだけでなく、効率的な継続的インテグレーションと継続的デリバリーを実現するために人材と思考を再構築する必要があります。企業や事業の種類によって、この目標を達成するために必要な道筋やテクノロジーは異なります。すべての企業には、自社、自社のビジネス、自社のチームに属する DevOps パスがあると言えます。すべての DevOps の方法と経験は、参考目的でのみ使用できます。本当の DevOps は自分で実践し、経験する必要があります。 WOT サミットは、DevOps の道を歩むすべての人が互いにコミュニケーションを取り、サポートし合うためのプラットフォームを提供します。