これをクラウドと呼ぶのか？

みなさんこんにちは、クン兄さんです。

長い間更新していませんでした。ここ数週間、体調がよくありません。重度の胃炎と頻脈の症状があります。私は何度か病院に行きました。ひどい時は心臓にとても不快感があり、胸が締め付けられて息切れし、死んでしまうような気がしました。時々一晩中よく眠れないこともありました。皆様には健康に気をつけていただくようアドバイスしたいと思います。夜更かしなど、身体を傷めるような愚かなことはしないでください。お体に気をつけて！

新年前後で0から1へのクラウドジャーニーを完了しました。多くの落とし穴に遭遇し、貴重な経験をたくさん積み重ねたので、ここにまとめました。誰もがこれを読んで恩恵を受けると信じています。

まず、今回のクラウド移行の背景についてお話しします。事業開始後、事業はグループから分離されましたが、システムはグループ内で共有されていました。システムの共有は大したことではありませんでしたが、グループは以前とは様変わりし、コアスタッフのほとんどが退職したため、一部のコアシステムが不安定になりました。リバース プロキシ レイヤーがダウンしたにもかかわらず、誰も修復しなかったためにトランザクション全体がゼロになってしまうという重大な事故もありました。そこで、システムとグループを完全に分離することにしました。グループシステムは以前 Tencent Cloud を使用してクラウドに移行されていたため、私たちも Tencent Cloud を使用し、ネットワークの相互運用性を実現し、移行するシステムのイメージの一部を共有できるようにしました。また、Tencent Cloud のツールを使用してデータの増分/完全移行を実行し、移行コストを削減することもできます。

クラウドサービスとは何ですか?

現在、クラウド コンピューティングは業界で認知されたトレンドです。Alibaba Cloud や Tencent Cloud などのクラウド ベンダーが、基本的に大手メーカーのシステムに必要なすべての側面をカバーする幅広いツールを提供しているためです。信じられませんか？大手メーカーの基本的なシステムアーキテクチャを見てみましょう。

完全かつ運用可能なシステムには、DNS 解決、CDN サービス、アクセス レイヤー、ミドルウェア、ストレージ レイヤー、APM などを提供する必要があることがわかります。クラウドにはこれらすべてのツールがあり、基本的にワンクリックで展開できます。ここに 2 つの簡単な例を示します。

• ZK クラスターの展開を例に挙げます。 ZK クラスターを展開する場合、通常は 3 台の仮想マシンに展開する必要があり (ZK クラスターには少なくとも 3 台のサーバーが必要です)、構成ファイルを編集する必要もあります。こうした手作業は面倒でエラーが発生しやすいことが多いですが、Tencent Cloud ではボタンをクリックするだけで ZK クラスターを自動的に生成できます。プロジェクト内の ZK クラスター アドレスを置き換えるだけです。基本情報（デプロイメントアーキテクチャ）、データ管理、動作監視（JVM、接続数、メモリ使用量など）、動作ログも表示できます。
• たとえば、Redis シャード クラスターを展開する場合、最初は 1 つのシャードだけが必要な場合がありますが、ビジネスが発展するにつれてシャード容量を拡張する必要があり、これはより面倒になります。通常、移行には公式の redis-trib 管理ソフトウェアを使用する必要があります。移行には、新しいノードの作成、クラスターへの新しいマスター ノードの追加、スロットの転送 (再シャーディング)、クラスターへのスレーブ ノードの追加が含まれます。これらの手順は非常に面倒ですが、Tencent Cloud 自体が提供するツールを使用する場合は、対応するシャーディング オプションを選択して [OK] をクリックするだけで、ワンクリックで完了します (以下を参照)。非常に便利です。同様に、Tencent Cloud は、Redis キャッシュヒット率、スロークエリ、CPU 使用率などの監視も提供します。

上記は単なる 2 つの簡単な例です。実際、Tencent Cloud は、MySQL、ES、MQ などのコンポーネントに対してワンクリック生成操作も提供しており、関連する監視およびアラーム メカニズムも備えているため、運用および保守コストが大幅に削減されます。これらのツールを使用する唯一の欠点は次のとおりです。

しかし、次のようなコストを管理する手段もいくつかあります。

• プロジェクトがイントラネット (運用センターなど) である場合は、コストを節約するために、これらすべてのプロジェクトを同じ低構成の仮想マシンに展開できます。
• 複数のオンラインフロントエンドプロジェクトを同一マシンに同時にデプロイすることも可能で、CDN と連携することでアクセスが遅いという問題を解決できます。
• APM を展開する必要がある場合 (分散呼び出しチェーンや JVM 監視などを表示するため)、データを収集するためにマシンに Skywalking などの分散トレース フレームワークを展開する必要があります。各サービスのすべてのマシンでデータを収集することは、実際には不要であり、コストが比較的高くなります。そこで、後で各サービスごとに収集用のマシンを 1 台だけになるように調整し、サンプリング レートを下げてアップロードされるデータ量を大幅に減らし、コストを削減することができました。この方法を採用した後、Skywalking によるデータ収集コストは 1 日あたり約 10 元に過ぎません。

データ移行

以前のシステムはグループで共有されていたため、独立させる必要があり、独立した構成センター、独立した Redis、独立した MQ、独立したデータベースが必要です...これらすべてを一夜にして達成することはできず、スムーズなデータ移行を実現することが必要であることは明らかです。具体的な操作は以下のとおりです。

• データベースの移行: Tencent Cloud のデータ移行サービスを使用して、完全アップグレードと増分アップグレードを実行します。データの一貫性を確保した後、すべてのデータ ソースをデータベースに切り取ります。
• 構成センターのデータ移行: 以前、グループは構成センターとして ZK を使用していたため、オープンソースで使いやすい移行ツール zkcopy を直接使用していました。次のコマンドを実行して、ZK データの移行を完了します。

 java - jar ターゲット/ zkcopy .jar --source サーバー:ポート/パス --target サーバー:ポート/パス

Redis の移行: 別の Redis インスタンス (ホストが異なるだけ) を作成し、元の Redis (グループ Redis) が書き込まれた後に AOP を使用して新しい Redis に書き込みます。基本的に、Redis データの移行が完了するまでには約 1 週間かかります。疑似コードは次のとおりです。

翻訳者
@側面
@成分
パブリッククラスAopRedisReadWriteAspect {

 @リソース
 プライベートRebateNewCacheClient rebateNewCacheClient ; //新しいRedisインスタンス
// RedisCacheClient はグループの Redis インスタンスです。 AOP を使用することで、グループの Redis を弊社の Redis インスタンスに同時に書き込み、同期することができます。
 //最終的にデータの一貫性を実現するために
 @Around (値= "実行(* com.xxx.RedisCacheClient.setex(" +
 "文字列、int、文字列)) && 引数(キー、有効期限、値)" )
 パブリックオブジェクトsetEx ( ProceedingJoinPoint joinPoint 、文字列キー、 int有効期限、文字列値) {
 rebateNewCacheClient .setEx (キー、有効期限、値) ;
 戻り値:invokeOrigin ( joinPoint ) ;
 }
プライベートオブジェクトinvokeOrigin ( ProceedingJoinPoint joinPoint ) {
 試す{
 joinPoint.proceed ( )を返します。
 }キャッチ(スロー可能な スロー可能な) {
 //ログを印刷
}
 nullを返します。
 }
 }

• MQ の移行: まず、MQ の作成は ZK クラスターの作成と同じくらい簡単です。パーティションの数などを決めるだけで、あとは指を動かしてクリックするだけで、各種監視やメッセージステータスのクエリなども含めて、ワンクリックで高可用性の RocketMQ クラスターが生成されます。自分でデプロイする場合は、おそらくかなり時間がかかります。移行中に、2つの準備を行いました。 1 つは、グループとブローカーに同時にメッセージを送信し、一部のユーザーをグレースケール化することです。これらのユーザーはブローカーにのみメッセージを送信します。問題がないことを確認した後、グループのブローカー ロジックへのメッセージの送信を停止し、スムーズな移行を実現します。

Ansible 入門

クラウド上には、Redis などのミドルウェアに素早くアクセスしたり、DB やその他のデータを素早く移行したりできるサービスが数多くありますが、これらとは別に、クラウド サービスが基本的に提供できるものは、他に何もする必要がないことを意味するものではありません。次に、この記事の焦点であるプロジェクト展開のアーキテクチャ設計について説明します。たとえば、Java プロジェクトを実行する場合は、まずそれをコンパイルしてパッケージ化 (jar パッケージを生成) する必要があります。パッケージ化して公開した後は、実行中のサービスをすぐに中断することはできません。エレガントなシャットダウン方法でサービスを停止し、新しいパッケージを展開する必要があります。デプロイ後に問題が見つかった場合は、ロールバックする必要があります。これらの手順を手動で実行するのは明らかに非現実的です。最善の方法は、スクリプトに記述して、ワンクリックで展開することです。ただし、サービスには複数のマシンが存在する場合があります。 1 つずつログインして、対応するデプロイメント スクリプトを手動でトリガーする必要がありますか?明らかに、これは非現実的です。より合理的な方法は、まずこれらのデプロイメント手順をすべてスクリプトの形式で記述し、次にバッチデプロイメントをサポートする自動運用および保守ツールを使用してデプロイメントすることです。調査の結果、Ansibleを選択しました。

Ansbile とは何ですか? また、その利点は何ですか?

Ansible は、ssh プロトコル接続を使用するだけで、バッチシステム構成、バッチプログラム展開、バッチコマンド実行などの機能を実現できるシンプルな運用保守自動化ツールです。

ansbile には次のような利点があります。

• SSH を介して対応するマシンの制御を引き継ぎます。対応するマシンでは Ansible クライアントをインストールする必要はなく、追加のサービスを有効にする必要もありません。そのため、Ansible がアップグレードされても、対応するマシンには影響しません。
• 日常的な操作とメンテナンスのモジュールが多数あり、ほとんどの日常的な操作を実現できます。
• シンプルな構成、強力な機能、強力なスケーラビリティ。
• 強力な構成とステータス管理は、Playbooks を通じてカスタマイズできます。いわゆるプレイブックは、YAML 形式のファイルです。このファイルでは複数のタスクが定義されており、これらの機能を完了するためにホストが使用する必要があるモジュール (主にコア モジュールとカスタム モジュール) が定義されています。

Ansibleは上記のような特徴から急速に普及し、運用・保守に必須のツールとも言えるようになりました。上の写真は Ansible のミニマリストバージョンです。アーキテクチャを少し拡張してみましょう。

実行フローは以下のとおりです。

• ユーザーは、(通常はジャンプ サーバー経由で) Ansible が配置されているマシンにログインします。
• ホスト インベントリを使用して、制御するホストを指定します。これは通常、YAML ファイルです。このファイルでは、制御できるすべてのホストを指定できます。別のサービスには通常、複数のマシンがあります。特定のサービスに属するマシンを指定することもできます。以下に簡単な例を示します。

全て：
 ホスト:
 10.100.1.2 :
 10.100.1.4 :
 10.100.1.5 :
 子供たち：
 建てる：
 ホスト:
 10.100.1.2 :
 オペレーションセンター:
 ホスト:
 10.100.1.4 :
 10.100.1.5 :

上図では、10.100.1.4 と 10.100.1.5 は同じサービス operator_center に属しています。このサービスを公開する場合は、サービス名 operator_center (以下で説明) を指定するだけです。

• ステップ 2 では、制御する必要があるマシンを指定できます。次に、Ansible は接続モジュール (つまり、SSH 接続を使用した接続プラグイン) を介して手順 2 で指定されたホストに接続し、コア モジュールを使用して対応する Playbook を記述して実行します。

Ansible には強力な機能を備えたコア モジュールが多数あります。基本的にカスタマイズする必要はありません。たとえば、クラウド移行にはコア モジュールのみを使用しました。一般的なモジュールをいくつか見てみましょう。

• シェル モジュール: シェル インタープリターを呼び出してリモート ホスト上でコマンドを実行でき、パイプラインなどのさまざまなシェル機能をサポートします。
• コピー モジュール: ファイルをリモート ホストにコピーし、指定されたコンテンツでのファイルの生成や権限の変更などをサポートします。
• ファイル モジュール: ファイルの作成、リンク ファイルの作成、ファイルの削除などのファイル属性を設定します。
• fetch モジュール: リモート ホストからローカル マシン (つまり、Ansible が配置されているマシン) にファイルを取得 (コピー) します。
• コマンド モジュール: リモート ホスト上でコマンドを実行し、その結果を呼び出し元のマシン (つまり、Ansible が配置されているホスト) に返します。
• Cron モジュール: 誰もがよく知っているスケジュールされたタスク モジュールです。

一般的なプロジェクトは、展開する前に構築（またはパッケージ化、この 2 つの概念に大きな違いはありません）する必要があることはわかっています。たとえば、Java プロジェクトは Jar ファイルにパッケージ化してからデプロイ (Jar パッケージを実行) する必要があります。フロントエンド プロジェクトも、デプロイする前にパッケージ化する必要があります (たとえば、複数の js ファイルを 1 つにマージして、リクエストを減らし、パフォーマンスを向上させることができます。たとえば、SCSS または less を使用して CSS を記述する場合、これも CSS ファイルにコンパイルしてマージする必要があります)。そこで疑問なのは、パッケージング操作を製造機械で直接実行できるかどうかです。答えは明らかに「ノー」です。主な理由は次の 2 つです。

• さまざまな最適化方法 (並列パッケージングなど) が使用されるため、パッケージングでは CPU の負荷が非常に高くなります。運用環境で外部サービスを提供しているマシンでパッケージ化操作を実行すると、パッケージ化中に CPU が過剰に消費されるため、現在実行中のマシンで応答が遅くなったり、要求が拒否されたりする可能性が高くなります。これは明らかに受け入れられないことです。
• サービスはクラスターの形で存在します。 1 つのサービスに複数のマシンが存在する場合があります。実際、これらのマシンへの展開に必要な jar パッケージはまったく同じです。各マシンでパッケージング操作を実行する必要はありません。

デプロイメントアーキテクチャ設計

要約すると、パッケージング作業を行うには専任のパッケージ担当者が必要です。パッケージャーがパッケージ化された後、対応するパッケージを運用マシンに送信し、デプロイメント スクリプトを実行します。アーキテクチャ モデルは次のとおりです。

このようにして、梱包担当者はすべての重労働を引き受けます。パッケージ化後、Ansible は fetch モジュールを通じてこれらの jar パッケージをローカルにプルし、push モジュールを通じてサービス クラスター内のすべてのマシンに jar パッケージをプッシュしてから、比較的軽量なデプロイメント スクリプトを実行します。

Ansible 関連の概念を多数紹介した後でも、まだ混乱しているかもしれません。次に、Ansible の機能について誰もがより包括的に理解できるように、Ansible を使用して、設計したパッケージ化とデプロイメントの手順を実行する方法を見てみましょう。

サンプルスクリプトを一つずつ紹介しましょう。3つのファイルがあります。

1.production-hosts.yaml ファイル: 上で説明したホスト インベントリ。

 #production -ホスト.yaml

 全て：
 ホスト:
 10.100.1.2 :
 10.100.1.4 :
 10.100.1.5 :
 子供たち：
 ビルド: # パッケージャー
 ホスト:
 10.100.1.2 :
 operation_center : #operation_center サービス
 ホスト:
 10.100.1.4 :
 10.100.1.5 :

2. パッケージ プレイブック: java-build.yaml;

 # java - .yamlをビルドする

-名前:ビルドプロジェクト成果物
 hosts : build // build は、本番環境のhosts.yamlファイルで定義されたパッケージャーを表します。
 タスク:
 - name :ソースコードをプルしてブランチをチェックアウトする
 ansible .builtin .git :
 repo : 'プロジェクトのgitアドレス'
 宛先:ワークスペース/オペレーションセンター
 バージョン:マスター
 強制：はい
- name : .shをビルドするための実行権限を付与する
 ansible .builtin .file : //ファイルモジュール
 パス: ワークスペース/operation_center/build.sh
 モード: '0755'
 - name :プロジェクトのビルド//パッケージ化スクリプトの実行
 ansible .builtin .shell : . / build .sh //シェルモジュール
 引数:
 chdir :ワークスペース/オペレーションセンター
 実行可能ファイル: / bin / bash
 - name :アーカイブ プロジェクトの作成//パッケージ化後、jar パッケージが生成されます。圧縮されるjarパッケージを保存するディレクトリを作成します
 ansible .builtin .file :
 パス: archive / operation_center
 状態:ディレクトリ
 引数:
 chdir : / home / buser
 - name :最新の成果物をアーカイブする//前の手順で作成したディレクトリに jar パッケージを圧縮します
 ansible .builtin .shell : cp ワークスペース/ operation_center /ターゲット/ operation_center .jarアーカイブ/ operation_center /最新の.jar
 引数:
 chdir : / home / buser
 - name :プロジェクトの成果物をローカルに取得する//フェッチ モジュールを使用して、圧縮された jar パッケージをパッケージャーから Ansible が配置されているマシンに取得します
 ansible .builtin .fetch :
 src :アーカイブ/ operation_center /最新の.jar
 保存先: / tmp / operation_center /
 フラット：はい
- name : bin ファイルをローカルに取得//デプロイメント スクリプトをパッケージャーからローカル マシンに取得し、オンライン マシンに転送してデプロイメント操作を実行する準備をします
 ansible .builtin .fetch :
 ソース: /home/buser/workspace/operation_center/deploy.sh
 保存先: / tmp / operation_center /
 フラット：はい

3. プレイブックをデプロイする: java-deploy.yaml;

 # java - .yamlをデプロイする

-名前:プロジェクトのデプロイ
 hosts : operation_center # は、production - hosts .yamlファイルで定義されたオンライン サーバーを表します。
 シリアル: 1
 any_errors_fatal : true # 1つのステップが失敗すると、デプロイメントプロセスは終了します
 タスク:
 - name :成果物をアップロードしてプロジェクトを再開
 ブロック：
 - name :プロジェクト成果物をリモートにプッシュ # ansbile 上の jar パッケージをサーバーにプッシュします
 ansible .builtin .copy :
 ソース: /tmp/operation_center/latest.jar
 dest : /opt/apps/business/operation_center.jar
 - name :デプロイファイルをリモートにプッシュ # ansbile 上のデプロイスクリプトをサーバーにプッシュします
 ansible .builtin .copy :
 ソース: /tmp/operation_center/deploy.sh
 保存先: / opt / apps / bin /

 -名前:オペレーションセンターを開始
 ansible .builtin .shell : bash bin / start .sh # デプロイメントスクリプトを実行する
 引数:
 chdir : / opt / apps
 実行可能ファイル: / bin / bash
 環境：
 アプリ環境: prod
 -名前:ヘルスチェック8001 # ヘルスチェック
 ウリ:
 URL : http://127.0.0.1:8001/service/health/deepCheck
 戻り値:はい
 ステータスコード: - 1
 登録:これ
 failed_when : 「'health' は this.content にありません」
 場合: health_check == "8001"
 -名前:ヘルスチェック8081
 ウリ:
 URL : http://127.0.0.1:8081/health/check
 戻り値:はい
 登録:これ
 failed_when : 「'health' は this.content にありません」
 場合: health_check == "8081"
 become : yes # 上記のデプロイメント手順をオンラインサーバー上でrootとして実行します
 ユーザになる:ルート

上記の 3 つのファイルでは、次のようにパッケージ化とデプロイメントの操作プレイブックをそれぞれ実行するだけです。

 ansible - playbook - i production - hosts .yaml java - build .yaml # パッケージャー内のパッケージ
ansible - playbook - i production - hosts .yaml java - deploy .yaml # オンラインサーバーにデプロイ

Ansible のコア モジュールを使用する限り、パッケージ化とデプロイメントの要件を満たすことができることがわかります。実行プロセスは上記の名前で表示され、デプロイメントプロセスは次のように表示されます。

プロセス展開プロセス全体が非常に明確であることがわかります。

便宜上、上記のスクリプトではパッケージ化と展開のいくつかの手順のみを簡単に紹介しています。実際には、ロールバックなどの操作も考慮する必要があります。本記事の主眼ではないのでここでは紹介しません。

話題から外れた話をしましょう

さまざまなクラウドベンダーが提供するツールは、実に広範囲にわたっており、使いやすいものです。ほぼすべての開発者がDevOps（開発と運用・保守）業務を担えるため、将来的に開発業務が置き換えられるのではないかという懸念があります。特に運用とメンテナンスが心配です。以前、運用・保守を担当している友人が、クラウドベンダーのツールはあまりにも使いやすいので、自分の仕事が奪われるのではないかと心配していると言っていました。実際、結局のところ、考えられるすべての運用および保守作業は基本的に 1 回のクリックで実行でき、データベースやミドルウェアなどの領域にも「浸食」されています。かつて、データベース チームのリーダーがクラウド移行に反対し、クラウド移行の多くのデメリットを指摘しましたが、クラウド移行のトレンドは止められず、いつか失業してしまうのではないかと心配していると個人的にも言っていました。

ある読者が次のような質問をしました。

私の答えは、クラウド ベンダーは実際にこのような非常に成熟したソリューションを提供しており、基本的に 1 回のクリックで生成できるため、この読者の魂を探る質問が生まれたということです。

多くの人がこの疑問を抱いていると思います。私の意見としては、クラウド サービス プロバイダーはツールのみを提供しますが、これらのツールを有効活用するには、依然として私たちが制御する必要があるため、次の提案をします。

開発者がより高いレベルに進みたい場合、しっかりとした理論的基礎と実践的な経験を習得する必要があります。それはまるで竜を倒す剣を与えているようなものです。深い内面の強さがなければ、それを使いこなし、うまく使いこなせるでしょうか?

この記事はWeChatの公式アカウント「Ma Hai」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、Mahai公式アカウントまでご連絡ください。