ハイブリッドクラウドへの適応、Huolala のデータベースミドルウェア構築への道

リン・ジン

JAVAテクノロジーエキスパート

Lalamove Technology Center のコアインフラストラクチャ部門の Java テクノロジエキスパートであり、データベースミドルウェアの研究開発に関する深い理解と豊富な実践経験を持っています。
モトローラの子会社である UniqueSoft で Java エキスパートとして勤務し、Java ベースの自動リバースエンジニアリングシステムの研究開発を主導しました。彼はアリババのローカルライフミドルウェアの技術専門家として勤務し、DALミドルウェアの研究開発を担当し、マルチアクティブシステムのグローバルコントロールセンターとデータ層の構築も担当していました。

今日の共有には主に次の側面が含まれます。

クラウド時代の到来とともに、インフラはクラウドに取って代わられるだろうという見方が以前からありました。インフラがなくなると、当然ミドルウェアを自分で構築する必要もなくなります。私の見解は正反対です。クラウド時代の到来により、さらに独自のミドルウェアを構築する必要性が高まっています。

なぜそう言うのでしょうか?主な理由は 2 つあります。1 つは技術的な適応の問題です。ネイティブ環境とクラウド環境は完全には一致しません。ビジネスをスムーズにクラウドに移行するには、ミドルウェアを使用して適応する必要があります。もう 1 つの重要な理由は、ベンダーの中立性を維持することです。さまざまなクラウドベンダーのサービスには統一された標準がありません。企業が特定の独自サービスに慣れてしまうと、クラウドプラットフォームを自由に選択できなくなります。したがって、独自のミドルウェアを構築することは、クラウド時代においては避けられない道です。そして、自作データベースミドルウェアは欠かせないものとなる―― 今回、皆さんと議論したいテーマはまさに「ハイブリッドクラウドへの適応、データベースミドルウェア構築への道」です！

1. 背景

ビジネス量の継続的な増加により、単一のデータベースのボトルネックが発生しました。
事業分野が拡大するにつれて、データベースの総量も拡大し続けます。
多言語の異種性、進化する技術基盤、新サービスから旧サービスへの移行。
マルチクラウドハイブリッドクラウドの展開。

ほとんどの成長企業と同様に、ビジネスが急成長するにつれて、技術的なシャーシにも独自の課題がありました。量的変化から質的変化へ、かつては当たり前だった多くの解決策はもはや完璧ではなくなりました。 DB が典型的な例です。単一の DB にまったくプレッシャーがなかった良い時代は終わりました。高い同時実行性と膨大なデータによるプレッシャーにより、DB はスループットとストレージの両方でボトルネックに遭遇し始めました。 DB の水位が高い場合、故障する可能性も最も高くなります。

ビジネスが充実し多様化するにつれ、従来のモノリシックアーキテクチャもマイクロサービスアーキテクチャへと進化し、PHP ベースのテクノロジースタックもさまざまな考慮により Java テクノロジースタックに移行しています。 DB レベルで明らかになるのは、データベースの解体、移行、構築に伴う膨大な作業です。この分野に精通している学生であれば、「倉庫の解体・移転」が時間がかかり、労働集約的で、リスクの高い作業であることを知っています。

ハイブリッドクラウドの背景により、問題の複雑さがさらに増します。ハイブリッドクラウドとは、アーキテクチャ設計がクロスクラウド特性を持ち、さまざまなクラウド環境に適応でき、特定のクラウドベンダーの独自製品に依存しないことを意味します。ビジネス開発の観点から見ると、基盤となる環境に適応するためにコード開発を繰り返す必要がない統合ソリューションです。

2. ハイブリッドクラウドの問題点と課題

異なるクラウドベンダーの RDS にはさまざまな違いがあります。
既存の線形 DB 拡張ソリューションはクラウドを越えることができません。
DB の頻繁な分割と結合は大きなリスクをもたらし、ビジネスに影響を及ぼす可能性があります。
DB レイヤー製品の変更にはコストが高く、新しいテクノロジのメリットをタイムリーに享受することは不可能です。

背景を紹介したところで、もう一度内容を確認してみましょう。

RDS には通常、クラウドプラットフォーム上で複数のオプションがありますが、マルチクラウドの状況では、Taobao で買い物をしているような感じになるかもしれません。一般的に言えば、このプロトコルは MySQL と互換性がありますが、特定の SQL 構文、マスター/スレーブ展開スキームなどの詳細に関しては、さまざまな微妙な違いがあります。たとえば、すべての SQL ステートメントをデータ削除に制限する場合は、where 条件が必要です。一部の製品はこの機能をサポートしておらず、一部の製品は動的な変更をサポートしている場合があり、一部の製品は再起動によってのみ変更できます。

先ほど、単一マシンのボトルネックについて触れましたが、クラウドベンダーは独自のソリューションを提供しています。初期のクラウドベンダーは、ライブラリとテーブルをシャーディングすることでデータベースの水平拡張をサポートする Alibaba Cloud の DRDS などの独自のデータベースミドルウェアを提供していました。沈殿と進化の期間を経て、クラウドベンダーは現在、より優れた操作性と保守性を提供するいくつかの新しい分散データベース製品をリリースしています。展開の詳細を心配する必要はなく、その線形拡張機能を直接楽しむことができます。これらの新製品は、単一のクラウド環境では非常に適したソリューションですが、問題は、これらのソリューションがクラウドをまたぐことができず、各クラウドベンダーの独自の製品に依存していることです。

もう一つの問題は変化です。データベースの分割を例に挙げてみましょう。 2 つの企業がデータベースを共有していますが、これを分割する必要があります。では、具体的な実行順序をどのように決めればよいのでしょうか?

① 新しいデータベースにデータを同期します。

② 事業の中断

③ 新しい文字列を使用してビジネスサービスが再起動されます。

④ 事業の回復。

このプロセスでは、ビジネスの自己中断能力に依存します。さらに、業務は長時間中断されるため、すべての業務ノードが再起動されたことを確認する必要があります。そうしないと、データの不整合による災害が発生します。何か問題が発生してロールバックが必要になった場合は、この長いプロセスを再度繰り返す必要があります。このとき、接続文字列を柔軟に制御し、それが指す DB を動的に設定できればよいと考えます。すべてを一度に切り替えることができ、問題が発生した場合には、中間の業務サービスを再起動することなく、すぐに切り替えることができます。

最後に、コストの問題について見てみましょう。クラウドベンダーは、強力な技術的背景と市場競争の圧力により、常に革新を起こし、コスト効率の高い新製品を発売して古い製品に代わることができます。低価格に惹かれますが、変化のリスクがあるため、軽率な行動を取るのを躊躇してしまいます。

3. ハイブリッドクラウドにおけるデータベースミドルウェアの構築

上記の問題をどのように解決すればよいでしょうか?核となるのは分離と適応です。どのように理解しますか?私たちが遭遇する問題のほとんどは、基盤となる RDS とビジネスサービス間の結合度が高いことに起因します。これは実際には過去には非常に合理的なアーキテクチャモデルでしたが、クラウド時代では、保守性と高可用性の要件を満たすことができなくなりました。したがって、独自のデータベースミドルウェアを構築してビジネスサービスとデータ層を分離する必要があり、同時に、データベースミドルウェアは DB 層を適応させて、ビジネスサービスに統一された一貫したエクスペリエンスを提供する必要があります。

この図から、ビジネス層と DB 層がデータベースミドルウェアを通じて分離されていることがわかります。このアーキテクチャでは、DB レイヤーの柔軟性とセキュリティが向上します。 DB レイヤー製品を柔軟に選択でき、クロスクラウド設計も可能です。

先ほどの DB 分割の問題に戻ると、新しいアーキテクチャでは次のように処理できます。

ビジネスサービスは、新しい文字列 (古いデータベースを指す) を使用して再起動されます。
データを新しいデータベースに同期します。
DBトラフィックの中断。
トラフィックは新しいライブラリに誘導されます。

ビジネスサービスでは、他の操作を実行せずに接続文字列を変更するだけで済みます。中断時間は非常に短くなり、増分データ同期が完了すればデータベースアクセスを回復できます。同時に、ロールバック操作も DBA チームによってクローズドループ化されました。当初は複数の関係者の協力を必要としていた変更が DBA チーム内のクローズドループアクションとなり、複雑さが大幅に軽減され、効率とセキュリティの両方が大幅に向上しました。

1. コア機能と特徴

前述のように、分離は、独自に構築されたデータベースミドルウェアによってもたらされるアーキテクチャの柔軟性によって解決されますが、適応はどのように行われるのでしょうか。適応は主にデータベースミドルウェアの特定の機能に反映されます。データベースミドルウェアの機能を設計および実装する際には、この点を考慮する必要があります。これらの機能について詳しく説明しましょう。

1) テンプレートベースのデータベースとテーブル分割、読み取りと書き込みの分離

データベースとテーブルのシャーディングは、現在最もコスト効率の高いデータベース線形拡張ソリューションであると言えます。主流の分散データベースミドルウェアはすべてこのソリューションを採用しています。

ビジネスR＆Dに提供される視点は、使用の視点です。ビジネス開発の観点から見ると、ビジネスの発展に合わせて必要に応じて DB 容量を拡張できる、新しいスケーラブルな MySQL データベースです。
DBA に提供される視点は、運用と保守の視点です。これは、シャードされたライブラリとテーブルで構成されるクラスターです。シャードされたライブラリとテーブルの数は、実際の DB 負荷に応じて調整されます。

ビジネス開発の観点と DBA の観点はどちらも比較的直感的であり、特に抽象的な概念は導入されていないことがわかります。 SQL 文の実際の実行は、構文解析、データベースとテーブルのシャーディングルールのマッピング、新しい SQL 文の生成、実行のためのシャーディングデータベースへの新しい SQL 文の送信、結果の集約など、非常に複雑です。これらの複雑なプロセスは重要ですが、ユーザーの観点からは価値というよりは負担となるため、データベースミドルウェアで詳細を非表示にすることで、すべての詳細を非表示にします。

通常の DB と同じ接続文字列をビジネス R&D の同僚に提供します。私たちが DBA に提供しているのは、新しい論理ライブラリを作成するための API です。パラメータはシャード数であり、具体的なハッシュ関数の選択、シャードテーブルの分散などについてはデフォルトのテンプレートが用意されています。これはまさにエンタープライズ向けのデータベースミドルウェアの特徴です。ユーザー自身がパラメータを調整する必要のある大規模で包括的な製品の作成は検討しません。代わりに、私たちは自社のビジネスの特性に応え、ベストプラクティスを備えた直感的な製品を直接提供していきます。

このデザインは非常に柔軟性があります。近い将来、コスト効率が高く、安定していると認められる新しいタイプのデータベースが登場するでしょう。論理ライブラリの実装を完全に置き換えることができ、再起動せずにビジネスサービスを直接使用できます。

2) マルチテナントとより効率的なリソース利用をサポート

マルチテナンシーは、クラウド時代のミドルウェアに不可欠な機能です。マルチテナンシーの中核は、リソースのプールとオンデマンドの共有にあり、これによりリソースの使用率を効果的に向上させたり、単純にコストを節約したりできます。

マルチテナント機能により、データベースミドルウェアはさまざまな使用シナリオに適応できるようになります。たとえば、DEV 環境では、データベースミドルウェアノードを使用してすべてのテスト DB をプロキシできるため、ビジネス R&D は、リソースの浪費を心配することなく、テストおよび開発フェーズ中に本番環境と一貫したエクスペリエンスを維持できます。

マルチテナントの設計と実装では、分離の 2 つの側面を考慮する必要があります。1 つは構成の分離であり、異なる論理ライブラリの動的な構成変更が互いに影響を及ぼしてはなりません。もう 1 つはリソースの分離です。異なる論理ライブラリの SQL 実行がリソースを競合しないようにする必要があります。

3) SQLリンクトラッキングとSQLガバナンス

SQL リンクトレースは、エンタープライズレベルの環境では非常に実用的かつ重要な機能です。問題のある SQL をキャッチした後、特定のソースをすぐに特定できるため、オンライントラブルシューティングの効率が大幅に向上し、障害回復が高速化され、損失が削減されます。この機能は、明らかに単一のミドルウェアでは実現できず、実現するには成熟したテクノロジシャーシと組み合わせる必要があります。

ここで言及しておくべき重要な点は、すべてのミドルウェアと同様に、データベースミドルウェア製品は、企業のテクノロジーシステムの一部になった場合にのみ、その価値を最大限に発揮できるということです。つまり、監視、構成センター、登録センターからのサポートを受けることができ、テクノロジーシステム全体に DB レイヤーのポイントオブケアデータとガバナンス機能を提供できるようになります。データアイランドになると、機能面と運用面で確実に欠陥が生じ、企業のテクノロジーシステムのブラックホールになる可能性もあります。

SQL ガバナンス機能には以下が含まれます。厳密な障害保護機能と緊急障害処理機能。
障害保護機能には、ピーク負荷の削減と電流制限、接続管理、SQL インターセプトと監査などが含まれます。
緊急障害処理機能には、SQL フロー制限インターセプト、SQL インデックスヒント挿入、メインデータベースの強制バインドの指定が含まれます。

SQL ガバナンスツールのセット全体は、さまざまなクラウド環境に適応し、DB の健全性と安定性を効果的に確保できます。

2. コアテクニカル指標

ここにいくつかの重要な指標があります。簡単に見てみましょう:

線形拡張限界: 単一マシン容量*1024
マルチテナント制限 - 単一クラスタの理論上の制限は10K

これら 2 つの指標は主に、現在のアーキテクチャソリューションが今後 2 ～ 3 年で会社の発展に対応できるかどうかという質問を考慮します。今後 3 年間で規模が 10 倍に拡大すると仮定した場合、当社のアーキテクチャはそれにスムーズに対応できるでしょうか?データ層の観点から見ると、答えは「はい」です。自社開発のデータベースミドルウェアをベースとしたデータベース層アーキテクチャは、将来的に 100 倍のビジネス成長を着実にサポートできます。

DB 移行の影響 - 数秒で中断

DB 移行影響指標は、移行機能の成熟度を表します。これは、ビジネスに損失を与えることなく移行できる当社の自由度を表しているとも言えます。数秒で中断できるため、ビジネスのオフピーク時にロスのない移行を実現できます。理想的な状況は、間違いなく一日中稼働できることであり、これは私たちが目指している方向でもあります。

低遅延 - 99.999%の遅延は10ミリ秒未満

低レイテンシインジケーターには、実際には、小さな RT 平均値と小さな RT ジッターという 2 つの側面での考慮事項が含まれます。データベースミドルウェアとしては、安定性が最優先です。通常、安定性を測定するためのコア指標として RT ジッターを選択します。技術的には、このディメンションインジケーターを改善するために、Netty NIO 多重化フレームワークと Java16 ZGC を選択しました。

高可用性 - 99.999% のサービス可用性

高可用性の定量的な指標は通常、X ナインとして表現されます。ここで、X ナインは、システムの 1 年間の使用中のシステムの通常使用時間と合計時間 (1 年) の比率を表します。一般的に、エンタープライズレベルのソフトウェアには 4 つの 9 が必要です。つまり、年間を通じて 50 分間のダウンが許容されるということです。ファイブナインとは、年間を通じてダウン時間が 5 分しか許されないことを意味します。しかし、当社のデータベースミドルウェアは、発売以来 16 か月間、障害ゼロを維持しており、この点については大変満足しています。

低コスト - コストはRDSの5%未満

いわゆる低コストというのは、ケーキを自分で作る方が買うよりも確実に安いということを意味します。もちろんこれは単なる冗談であり、絶対にそのように考えることはできません。ここで関係するコストは、ソフトウェアとハードウェアのコスト、運用と保守のコスト、研究開発のコストの 3 つです。最初の 2 つは誰もがよく知っていると思います。

私は主に、3 番目のコストについての私の見解を共有したいと思います。誰もがすべてを自分で開発したいと考えていた過去とは対照的に、現在は自己研究投資のコストを誇張し、自己研究の選択肢を直接放棄する傾向があります。オープンソースの雰囲気が強いミドルウェア分野では、実は以前よりもミドルウェアの人材を育成しやすくなっています。また、コミュニティのリソースを活用することで関連する問題を解決できるという自信も高まっており、研究開発のコストもそれほど高くなりません。 R&D実践後にはコミュニティにフィードバックを提供することもできるため、好循環が形成されます。これは双方にとって有利な選択です。

3. 操作性と技術設計

操作性は、ミドルウェア製品の設計が「使いやすい」かどうかを測る上で重要な側面です。発売後の製品ライフサイクルを対象とするものですが、設計段階で決定されます。操作性の内容はかなり豊富です。当社製品の構築プロセスを総括し、考察した結果、以下の4点にまとめました。

1) 失敗を考慮した設計

コア以外の依存関係はダウングレードできる
コア依存関係は冗長である
システムの「無実を証明する」能力を構築する
最後の防衛ラインマニュアルSOP

失敗志向設計は誰もがよく知っている概念であるはずです。特に規模が大きくなってくると、失敗は避けられなくなります。機械が 1 台しかない場合は、「今日は故障するかもしれない」と言えますが、機械が 10,000 台ある場合は、「今日は必ず 1 台が故障する」と断言できます。特に注目すべきは、クラウドに移行すれば障害は発生しないと考え、クラウド環境の安定性を神格化してしまうことがある点です。クラウド環境の安定性は、障害が発生しないことを意味するのではなく、障害回復のための完全なメカニズムセットが存在すること、つまり脆弱性対策設計を意味します。ただし、一部の障害、特にハードウェア障害には、迅速な回復方法がありません。たとえば、スイッチが壊れると、復旧はもちろん、問題を発見するだけでも長い時間がかかります。したがって、環境がどのようなものであっても、障害に備えた適切な緊急時対応計画を設計する必要があります。

データベースミドルウェアのシナリオでは、ダウングレード可能な依存関係は、一般的に、バイパス、動的構成変更、監視などに影響する機能を指します。ダウングレード不可能な部分には、重要なデータ、ハードウェア機器などが含まれます。データは必ずバックアップする必要があります。また、別の観点から見ると、ハードウェアの問題は実際には単一ノードの障害に近いため、クラスタリングは非常に適したソリューションです。

大規模なシステムで障害が発生すると、あちこちから煙が上がっているのが見えるものの、実際の問題箇所を見つけるのは困難です。このとき、「無実を証明する」ということが非常に重要になります。すべてのコンポーネントが自身の状態を素早く判断できれば、障害箇所が明確にわかります。もちろん、「無実を証明する」というのは、そう簡単なことではありません。実際の状況では、システム全体が故障することが多く、自分のモジュールに問題があるかどうかは誰にもわかりません。その後、ログを見て監視を確認しますが、そのような努力をしても結論を導き出すのは困難です。「無実を証明する」ことは、現場に対する深い理解と、監視や警報などの基本的な機能の調整を必要とする、重要かつ非常に難しい能力です。データベースミドルウェアでは、主に内部ワーカースレッドの負荷、外部 RT、ネットワークパケット損失という 3 つの重要なデータに焦点を当てています。

手動 SOP はフォールバック対策です。たとえば、データベースミドルウェアはローカルファイルを起動する機能を保持します。

2) 製品の標準化

異なる使用特性に基づいてグループを分離する
統一されたハードウェアとソフトウェアの標準を使用する
既存のエンタープライズ標準を可能な限り再利用する
アクセス標準化
単純関数と直交関数

標準化とは、全体最適を追求する設計思想です。

1つは機能設計の標準化です。基本的なミドルウェアとして、私たちの機能はシンプルで直交している必要があります。そうすることで、機能を実装する際に品質の確保に重点を置きながら、さらなるオーケストレーションの余地を残すことができます。例えば、指定したSQLクエリを制限する機能や、異常なSQL（SQLの長さが長すぎるなど）を報告する機能も提供しています。このとき、上位レベルのコントロールプレーンに異常な SQL を自動的に制限する機能が備わっていれば、非常にスムーズになり、実装が容易になり、グレースケールのロールバックにも便利になります。最初からデータベースミドルウェアに大きな動きを起こそうとすると、このような容易さを実現するのは難しいでしょう。むしろ、機能の相互影響、複雑性の高さ、バグの導入により、反復のリズムが乱れる可能性が高くなります。

もう 1 つは、外部依存関係の標準化です。たとえば、在庫切れマシンの問題を回避するために、会社の統合 ECS モデルを使用するようにします。同社の統一された基本コンポーネントを使用することで、追加のメンテナンスコストを回避しながら、製品開発の効率と安定性を向上させることができます。

最後に、ユーザーの使用法の標準化があります。ユーザーに不確実性を与えすぎないようにし、代わりに 1 つの標準的な回答のみを提供する必要があります。一連のベストプラクティスを統一し、これに基づいてサポートの最適化を行う必要があります。この方法により、ユーザーはプロセスに簡単にアクセスし、他のユーザーに簡単にコピーできます。効率性を向上させると同時に、無理な使用姿勢による故障も回避します。

3) インテリジェントなトラブルシューティング

サービス監視、システム監視、外部依存関係監視
リンクトラッキング
自動アラーム

監視の重要性は疑う余地がありません。失敗してから各種監視指標を補足するのではなく、開発計画の最初から監視ポイントを組み込む必要があります。

監視ポイントの重要なポイントは、データフローと制御フロー、正常プロセスと異常プロセスを含む製品の主要なプロセスを完全にカバーすることです。このときに犯しやすい間違いは、埋もれたデータを早期に処理してしまうことです。たとえば、内部に作業キューがある場合、キューがビジーかどうかを示すために特定のしきい値に基づいてポイントをマークするのではなく、キューの長さを直接印刷する方が適切です。このように、チャートを使用してキューの混雑状況の変化を表示し、アラームを柔軟に設定できます。アラームは、値が 0 のアイドル異常アラーム、または値が 100 のビジー異常アラームになります。

アラーム、リンク、監視などはすべてトラブルシューティングのためのものなので、トラブルシューティングの利便性の観点からこれらのインジケーターポイントを設計し、受け入れる必要があります。ある点が必要かどうか疑問に思った場合、オンライントラブルシューティングでそれが役立つかどうかを確認できます。

オンライントラブルシューティングは「インテリジェント」であるべきだと言いますが、私たちが本当に実現したいのは「絶対確実な」トラブルシューティングプランです。障害が発生するとすぐにアラームを受信し、リンク追跡ツールを通じて直接根本原因を見つけ、最終的に計画に従って段階的に対処することができます。

4) 管理の自動化

最終的には手作業のプロセスを「排除」する
ユーザーセルフサービス

自動化によって効率が向上するというのが私たちの共通認識です。自動化により、大量の反復作業から解放され、作業効率が向上します。

では、数量がそれほど多くなく、部品がそれほど重複していない場合はどうなるでしょうか?監査やその他のアクションなどの自動化の必要性はありますか?

それは必要だと思います。ある部分を自動化できないことがわかり、手動で「なんとか」やり遂げたいと思ったとき、これは私たちが十分に考え抜いていないことであることが多いです。この問題を徹底的に解決しなければ、この問題は犬の皮の絆創膏のようにユーザーエクスペリエンスを低下させ続けることになります。以前にも、新しいロジックライブラリを作成すると古いロジックライブラリに影響が及ぶ可能性があるという状況に遭遇したことがあります。ユーザーが誤った情報を入力して例外が発生するのを防ぐために、手動によるレビューを複数回実施しました。実際、手動レビューでは問題は解決されず、全体的な自動化が妨げられます。最後に、ロジックライブラリの構成分離とロールバック機能を再設計したため、自動化の問題はなくなりました。

手動プロセスを「排除する」ということは、主に、私たちが見て見ぬふりをしている製品の潜在的な問題を取り除くことを意味します。

ユーザーセルフサービスも同様です。自らを助けることができるシステムとはどういう意味ですか?これは、当社のシステムが堅牢かつ安定しており、優れた分離設計と強力なフォールトトレランスを備えていることを意味します。自己啓発を目標にすることは、より良い製品を構築するための大きな動機になります。

一般的に、保守性はソフトウェアの後の段階で投資する必要がある「隠れたコスト」に影響し、高い収益をもたらす長期的な投資となります。