JD Financeのアプリケーション中心のDevOpsシステム構築

DevOps は、アジャイル、スクラム、XP から進化し、運用と保守の分野にまで広がった新しい動きです。

みなさんこんにちは。私はJD FinanceのPEチームの責任者、Wang Chaoです。 PE の役職についてよく知らない人も多いかもしれません。この職種は、Yahoo、Alibaba、Facebook など多くのインターネット企業に存在します。正式名称はプロダクト エンジニア (プロダクト オペレーション エンジニア) で、アプリケーション オペレーションと呼ぶ企業もあります。

簡単に言えば、生産環境における製品の技術的な操作と定義できます。 JD Finance におけるすべての本番環境の業務運用と保守、ビッグデータとミドルウェアの運用と保守は、PE チームが主導するか、主に参加する必要があります。

私の過去の経験は、Renren.com で PE 運用保守チームを担当したことであり、それ以前は伝統的な大規模国有企業でアプリケーションの運用保守を担当していました。

3 社のキャリア開発の軌跡を見ると、伝統的な業界から大手インターネット企業、そしてインターネット金融へと、さまざまな転職を経験してきました。さまざまな経験が私にさまざまな視点を与えてくれました。それを皆さんと共有したいと思っています。

運用保守システムの4つの象限

運用および保守システムは、速度、品質、コスト、安​​全性の 4 つの主要な側面に重点を置いています。

スピード

企業にとって最も重要なことは、いかにしてより大きなビジネス価値を生み出すかということです。製品は迅速にリリースする必要があり、技術的なボトルネックによって迅速なビジネスの反復や新製品の発売およびプロモーションが制約されることがあってはなりません。

品質

サービスを迅速に提供するには、オンライン品質を保証する必要があります。

料金

人件費と IT 運用コストは、常にインターネット企業の 2 大支出となってきました。大規模なインターネット企業の場合、サーバーの規模は数万台から数十万台になります。リソースの最適化、サービスパフォーマンスの向上、水路容量の合理的な評価、予算策定、原価計算なども、運用と保守で実行する必要があるタスクです。

安全性

セキュリティは、特に金融業界にとって非常に重要です。決済業界には「キャピタルロス」という用語があり、これは資金が失われることを意味します。取引プロセス中に、注文やマーケティング活動が繰り返される場合があります。たとえば、ユーザーに多額のお金が渡され、ユーザーがそのお金を引き出すと、そのお金は回収できず、経済的損失が発生します。

技術上または業務上の問題により、数千万またはそれ以上の経済的損失が発生する可能性があるため、金融業界の運用・保守担当者はセキュリティの問題に注意を払う必要があります。

DevOps入門

DevOps は、アジャイル、スクラム、XP から派生した新しい動きであり、運用と保守の分野にまで広がっています。

DevOpsが解決する問題

DevOps は、開発、QA テスト、技術的な運用と保守の 3 つの役割を調整し、それらの間の緊密なコミュニケーションとコラボレーションを強化します。

DevOp は、プロジェクトの計画、コード開発、構築、テストからリリース、展開、運用、監視まで、継続的かつ中断のない反復的なリリースと展開を維持する閉ループです。

その中で、最後のいくつかのリンク、つまり運用監視と需要側へのフィードバックは、見落とされがちです。ただし、DevOps ではフィードバックの重要性が強調されます。導入が完了したら、要望を提案した人に通知し、ビジネス側が確認して、結果が検証されていることを確認する必要があります。

DevOps マスター サンドボックス トレーニングに参加したことがある方は、この点について深く理解しているはずです。ビジネスにおける DevOps の最も重要な役割は、ビジネス戦略の迅速な推進と迅速なフィードバックを確保することです。

開発と運用・保守の間には部門の壁が存在することがよくあります。その理由の 1 つは、運用と保守ではセキュリティと安定性に重点を置き、開発ではオンラインリリースのスピードに重点を置いていることです。問題について考える出発点が異なると、理解が異なり、コミュニケーションが不十分になります。

運用環境の安定性を確保するため、運用と保守では、1 週間に 1 つのオンライン ウィンドウのみを設定し、毎週水曜日の夜に 1 回オンラインになる場合があります。開発側は、ビジネスを緊急にオンライン化する必要があるため、それほど長く待つことはできないと感じるかもしれません。

これは単なる技術的な問題ではなく、ビジネスおよび組織構造の管理の問題も関係しています。まず、DevOps の観点から問題を分析してみましょう。

DevOpsは、変更が小さく、頻繁に行われるほどリスクが減ると考えています。

従来の企業 IT では、月に 1 回または四半期に 1 回しかバージョンがリリースされない場合がありますが、インターネット企業の場合、このサイクルは長すぎます。

たとえば、週末にプロモーション イベントを開催したり、Web サイトに新しいページを公開したりする緊急の要件があるのに、運用と保守担当者が来月までオンラインにならないと言った場合、それはもはやビジネスにとって価値がなくなります。したがって、テクノロジーはより迅速かつ頻繁な変更をサポートする必要があります。

要件を細かく分割すると、毎回変更されるコードの量が少なくなり、その部分のテストがより明確になり、コードレビューが速くなるため、リスクをより低く抑えることができ、問題が見つかった場合はすぐにロールバックして解決することができます。

開発者に本番環境のコントロール権限を与える

開発者が本番環境をより細かく制御できるようにしますが、運用上のリスクを制御する必要があるため、開発者に運用を操作および保守する権限を単に与えるだけではいけません。

JD Finance を例にとると、開発者が制作や運用・保守に参加できるようにしていますが、マシンに直接ログインして操作するわけではありません。代わりに、アプリケーションの作成、リリースと展開、起動と停止など、運用および保守プラットフォーム上での制限された操作を許可します。

また、開発者がサーバーにログインしなくても、ログを表示したり、サービスの状態を確認したり、プラットフォーム上で他の操作を実行したりできるように、対応する監視システムとログ プラットフォームを提供する必要があります。

アプリケーション中心のアプローチでインフラストラクチャを理解する

アプリケーションが基盤となる環境に依存しているかどうか、物理マシンと仮想マシンのどちらで公開されているか、ビジネス ニーズに基づいてどの程度の規模のサービス ノードを展開する必要があるかなど。

複数のコンピュータ ルームに展開する場合は、オンラインになる前に R&D の同僚と同様の問題についてコミュニケーションを取り、全体的な技術アーキテクチャと展開アーキテクチャを策定したいと考えています。 R&D の同僚がインフラストラクチャをより深く理解することは、全体的なアーキテクチャの最適化に非常に役立ちます。

シンプルで明確なプロセスを設計し、可能な限り自動化する

人、プロセス、テクノロジーは、テクノロジー管理において非常に重要な要素です。人によって考え方は違いますし、考え方も違います。また、インターネット企業では人材の入れ替わりが激しいため、人をコントロールすることが難しいのが実情です。

プロセスは重要ですが、プロセスが人間の合意に基づいてのみ実行され、適切に実装されなければ、効果は確実に良くなりません。したがって、私たちのアプローチは、プラットフォームに依存し、プロセスをプラットフォームに固め、プラットフォーム上でのリスクの高い操作を回避することです。

ガイド付きのプロセスを通じて、アプリケーション プロジェクトの確立、アプリケーションのリリース、容量の拡張と削減、その他の操作を完了できます。各ステップで適切なプロンプトが表示されるため、誤操作はほとんどありません。

開発者と運用スタッフ間のコラボレーションを促進する

DevOps の最終的な目標は、パイプライン形式のジャストインタイム (JIT) ビジネス プロセスを確立して、ビジネス成果を最大化することです。ビジネス成果の最終的な測定は、ビジネス提供の完了の指標、つまり、ビジネスが時間どおりに開始されたかどうか、開始後にビジネス担当者によって承認されたかどうかに基づく必要があります。

コンウェイの法則は、システムを設計する組織によって作成された設計とアーキテクチャは、組織間の通信構造と同等であると述べています。逆に言えば、システム設計やアーキテクチャがそれをサポートしていない場合は、効果的な組織をうまく構築することはできません。

企業によって組織構造が異なり、サービス構造も異なることがよくあります。 DevOps シナリオで合理的な組織構造をどのように設計するかについても、検討する必要がある問題です。

組織構造を設計する際に、最も興味深いことの 1 つは、効率的な小規模の開発および配信チームをどのように構築するかということです。上の写真の「ピザ 2 枚チーム」のように、チームにピザ 2 枚を提供できない場合は、チームが大きすぎます。

効率的な組織構造を実現するためには、トップレベルの小規模なチーム間でのコミュニケーションと交流を増やす必要があるため、コミュニケーションを促進する組織構造をどのように設計するかも重要です。

上図のように、上部は開発、製品、テスト、下部はSA、DBA、運用保守開発、セキュリティ、ネットワークの各部門に相当します。 PEの役割は、お互いを結びつける役割を果たします。

PE の役割は、特殊部隊の役割に少し似ています。特殊部隊は3人組で野外任務を遂行することが多い。この3人の間では何らかの分業があるのか​​もしれません。戦略的な指揮に重点を置く者もいれば、任務遂行を担当する者、連絡と通信を担当する者もいます。

この3人の後ろには、後方支援を行う数百人の人々がいることが多いです。兵站要員は特殊部隊のカメラなどの装備を使い、送られてきた情報をデータ分析し、特殊部隊の行動経路や実行計画を指示する。

参考までに、私たちの運用・保守業務においても、製品・開発担当者とより直接的にコミュニケーションを取り、ニーズを理解し、ニーズに基づいたソリューションを開発し、遭遇する問題を解決するために、小規模で柔軟なチームが必要であると考えています。

そのため、私が担当する PE チームでは、3 ～ 4 人のグループに分かれて、特定の事業ラインをフォローするようにしています。各人が対応するビジネスについて可能な限り多くを学ぶことができます。他の運用保守部門の協力が必要な場合、これらのビジネス要件は運用保守用語に変換され、運用保守内の他の部門に引き継がれます。

DevOpsの原則

• DevOps の公式の 5 つの原則は次のとおりです。
• 文化
• オートメーション
• 傾く
• 測定
• 共有

データ測定（計測）に注目してみましょう。

監視が適切に行われないと、小さな問題を検出することが容易ではなく、問題が発生すると大きな業務中断を引き起こします。

大手インターネット企業の監視ツールは、一般的にレイテンシに対して非常に敏感です。たとえば、社内で広く使用されている APM アプリケーション レベルのパフォーマンス監視ツールでは、アプリケーションのサービス インターフェイスのパフォーマンスが 100 ミリ秒から 120 ミリ秒に変化すると、アラームがトリガーされる可能性があります。このアラームにより、インターフェイスのパフォーマンスが遅い理由がハードウェアの問題なのか、ネットワークの問題なのかを全員が確認するようになります。運用保守チームは開発チームと協力して詳細な調査を実施します。

これらの小さな問題により、私たちはより技術的に考えるようになり、問題のトラブルシューティングを行うために、よりきめ細かい監視および分析ツールを開発するようになりました。

DevOpsシステム構築

アプリケーションライフサイクル管理

アプリケーションには、プロジェクトの確立からリリース、オンライン リリース、継続的な反復的な変更、拡張、縮小、移行、およびライフ サイクル終了時のオフラインまでの完全なライフ サイクル管理が必要です。

アプリケーションのライフサイクル全体を管理する際には、内部プロセスシステム、アプリケーション情報管理システム、自動デプロイメントシステムを組み合わせ、外部にAPIインターフェースを提供します。

アプリケーション センターは CMDB に似ていますが、CMDB はオペレーティング システム、物理マシン、ネットワーク、データ センターの管理など、基盤となるインフラストラクチャに重点を置いています。ただし、アプリケーション ライフ サイクルは、アプリケーション自体と周囲の関連システムに重点が置かれます。

アプリケーション プロジェクトを確立する際には、使用するリソース パッケージの決定、ビジネス キャパシティに基づいた必要なノード数の計画、基本コンポーネントのバージョン、ネットワーク トポロジ、ネットワーク アプリケーション、ネットワーク権限など、多くの作業を行う必要があります。また、プロジェクト確立後には多くの情報変更も発生します。

すべての変更を記録するために文書のみに頼っていると、引き継ぎプロセス中に情報が見落とされたり失われたりしやすくなり、引き継いだ人のその後の業務にリスクをもたらします。システム間の自動転送時にアプリケーション情報を自動的に記録することで、アプリケーション情報と本番環境の一貫性が確保されます。

この情報は、外部へのサービス インターフェースとしても提供されます。たとえば、アプリケーション監視構成がアプリケーション システムから独立して維持されている場合、アプリケーションの容量が拡張または縮小されるたびに、監視システムに変更を通知する必要があります。これにより、アプリケーションの拡張または移行後に監視が漏れやすくなり、潜在的なリスクが生じる可能性があります。

ただし、監視システムは、アプリケーション センターから提供されるインターフェイス データを基本情報として使用するため、データがリアルタイムかつ正確であることが保証され、各システムを再構成する必要がなくなります。

コードとしてのインフラストラクチャ - DevOps の基盤

アプリケーションの展開は基本環境に大きく依存します。たとえば、Python プログラムの展開は、Python のバージョン、基盤となる OpenSSL およびその他のファイル ライブラリ、およびオペレーティング システムによって異なります。

初期の頃は、多くの操作とメンテナンスがスクリプトと設定ファイルを通じてバッチで実行されていました。必要な依存環境が決定され、順番にインストールされました。各実行の前に、操作対象の IP リスト ファイルなど、スクリプトまたは構成ファイルの内容を一時的に変更する必要がある場合があります。このアプローチは、タスクが複雑な場合や複数の人が関与している場合に、より大きなリスクをもたらします。

Puppet、Ansible、Chef などの構成管理ツールは、この問題を非常にうまく解決します。これらのツールは、Ansible Playbook によるソフトウェア展開の依存関係の定義、ロールのグループ化による実行ターゲット状態の厳密な制御、操作の繰り返しなど、より多くの構成管理方法を使用するようにガイドします。リンク内の問題も正確に特定できるため、結果の保護が向上します。

コンテナ時代の到来により、まず第一に環境の一貫性の問題がよりよく解決されました。基本環境はイメージのカプセル化によってコンテナ イメージにパッケージ化され、開発、テスト、本番までの環境の一貫性が確保されました。

Mesos や Kubernetes などのプロセス オーケストレーション ツールは、デプロイメントの問題をより適切に解決します。アプリケーション情報と展開の規模にのみ焦点を当てる必要があります。このプラットフォームはほとんどの問題を解決しました。

技術アーキテクチャに精通している

開発者と同様に、運用および保守担当者も技術アーキテクチャとビジネス アーキテクチャについて詳しく知る必要があります。

技術アーキテクチャとビジネス アーキテクチャについて詳しく知ることで、運用中に問題に遭遇したときに問題をよりよく理解して対処できるようになり、R&D によって提起された要件を理解するときに問題をよりよく理解できるようになり、さらにはより優れたソリューションを考案できるようになります。

プラットフォーム・アズ・コード

ビジネス アーキテクチャで主に使用される基本コンポーネント:

• GSLB
• ゲートウェイ
• サービス指向コンポーネント
• メッセージミドルウェア
• キャッシュ
• 構成管理プラットフォーム
• 分散スケジューリング
• オーストラリア
• ログプラットフォーム

今後の展望

デジタル運用と保守

運用保守業界も細分化され、業務運用保守の役割はますますデータベース運用に近づき、アプリケーションのライフサイクル全体を通じて継続的なフォローアップと最適化が行われ、反復の高速化、アクセス品質の向上、セキュリティの脅威、コスト分析に重点が置かれるようになります。これらの課題は、当社の継続的な技術の深化とビジネスへの価値提供を促進します。

品質を向上させるには、次のデータ監視を行う必要があります。

• 基本的なサービス監視（ネットワーク、OS、DNSなど）
• データ サービスの監視 (DB、キャッシュ、メッセージなど)
• アプリケーションパフォーマンス監視
• 分散型通話追跡と監視
• ログ監視
• ビジネス指標の監視

インテリジェントな運用と保守 - AIOps

AIOps も非常に人気のある研究分野です。考慮すべき重要なポイントは次のとおりです。

• データの収集が基礎であり、イベント情報が要約され、データにラベルを付ける必要がある。
• 根本原因を見つけるためのアラーム相関分析。
• 自動アラームダウングレードまたはエスカレーション。
• 容量水位推定および自動容量拡張。
• 手動ルールから機械学習への移行。

後ほど詳細をお伝えする時間を見つけたいと思います。

[[239196]]

Wang Chao 氏は、JD Finance のシニア テクニカル アーキテクトであり、アプリケーション運用保守チーム (PE チーム) の責任者です。彼はまた、Renren.com の PE チームを率いていました。私たちは、JD Finance の運用保守システムの 0 から N までのプロセスと、いくつかの 618 および Double Eleven プロモーションのテストを経験しました。現在はDevOps、運用・保守とアーキテクチャの統合、ビジネス可用性の確保、運用・保守プラットフォームの構築、チーム管理などに注力しています。