IOE を排除するための 9 年間の戦い: OceanBase がダークホースとして浮上した経緯を詳しく見る

過去 10 年間、クラウド コンピューティングによってもたらされた変化により、従来の IOE アーキテクチャが企業の運用コストに与える影響と、将来のビジネス開発に対する制約が徐々に強まってきました。

[[226338]]

特に、大規模、高同時実行、リアルタイム オンライン、大規模ネットワークの最適化など、インターネットの新たな需要により、従来の IT 環境向けに設計された Oracle データベースでは、インターネット企業のますます大規模化するデータ量を処理することがますます困難になっています。

そこで、超大規模インターネット企業の分散コンピューティング環境向けに再開発されたリレーショナルデータベース「OceanBase」が誕生しました。

Ant Financialが開発した分散型リレーショナルデータベースであるOceanBaseは、Alibabaが「脱IOE」の構想を提唱した2008年から、Ant Financialが「脱IOE」を本格的に実現した2017年まで、想像を絶する数々の試練を乗り越え、国内外に影響を与えた多くの成果を上げてきました。

この記事では、OceanBase を詳しく調べ、その研究開発プロセスと方法論をたどります。

R&Dストーリー: ソフトウェア、ハードウェア、ビジネス統合

以下は、説明のための典型的なケースのほんの一部です。

ビジネスを統合し、ソフトウェアとハ​​ードウェア全体を最適化

アント・ファイナンシャル基礎データ部（OceanBaseチーム）でSQL関連の開発業務を担当する陳孟孟氏は、これまでデータベース技術はソフトウェア層に偏っており、ハードウェア層にはハードウェア自体の安定性や災害復旧などの問題を解決する専門家、専門技術、専門企業が存在していたと語った。

しかし、Ant Financial のソリューションは、ソフトウェアとハ​​ードウェアを組み合わせたものです。 OceanBase ソフトウェアは、設計当初からハードウェア レベルの不安定性と分散システムの特性を考慮しており、従来のデータベースでは実行できなかった最適化作業を実行できます。

以前のデータベース最適化では、基礎となるハードウェアの損傷、マシンの故障、ネットワークの停止、自然災害、人為的災害などの不確実性が考慮されていませんでしたが、現在 OceanBase ではこれらの問題を常に考慮しています。

「以前は、ソフトウェアを開発する際には、基盤となるハードウェアに問題はなく、上位レベルのソフトウェア ロジックをうまく処理するだけでよいと想定していました。現在は、ハードウェアとソフトウェア全体を考慮しています。」

データベースクエリ最適化技術を例にとると、従来の銀行のカウンターは手動の窓口を通じてサービスを提供しており、ユーザーはほとんどの時間を手動の窓口での対応に費やしているため、データベースの速度にはそれほど敏感ではありません。

しかし、Ant Financial はインターネット アプリケーションであるため、データベースが不安定になったり、クエリの実行速度が少し遅くなったりすると、ユーザーはすぐにそれを感じます。

これは従来のアプリケーションシナリオとは大きく異なります。データベースクエリが 1 ミリ秒から 5 ミリ秒に変更されても、従来のデータベースでは大きな問題とは見なされません。

ただし、インターネット アプリケーションでは、追加の 4 ミリ秒が数百ミリ秒、あるいは 1 秒や 2 秒にまで拡大される可能性があります。このような遅延が発生すると、ユーザー エクスペリエンスはすぐに低下します。

「私たちは毎日非常に細かいことをやっています。1ミリ秒が5ミリ秒になってしまうのではないかと不安なので、精密な防御をたくさん行っています。」

Ant Financial の基本データ部門 (OceanBase チーム) の研究者である Yang Chuanhui 氏は、さらに次のように説明しています。「データベース クエリ オプティマイザー自体は近似解です。基本的に、最適な解決策はありません。最適化の目標は、最も理想的な状況に近づくことです。

従来のアプリケーション シナリオでは、最適化の結果が数ミリ秒以上異なることが許容される場合があります。ただし、インターネットのシナリオでは、このような大きな差を受け入れることは難しく、すべての最適化効果は数ミリ秒以内の精度でなければなりません。

たとえば、Alipay で支払いをして支払いボタンをクリックするたびに、その背後にあるデータベースはデータベースの SQL クエリを 100 ～ 200 件実行する必要があり、オプティマイザーはクエリごとに最適化された実行プランを生成する必要があります。

特定のシナリオでオプティマイザーがミスを犯し、各クエリに 5 ミリ秒長くかかると、リンク全体に 500 ミリ秒長くかかることになり、ユーザーは支払いボタンを押したときにインタラクション速度が低下したことに気付く可能性があります。

支払い以外の可能性（たとえば、商品を注文した後に支払いをする必要があるなど）を追加すると、これらのリンクを組み合わせると、数百ミリ秒、あるいは数秒も遅くなる可能性があり、これはユーザーにとって受け入れられません。

顔認証やアリペイを使って地下鉄に入る場面もある。ユーザーが改札口の前で長時間立っていてカードをスワイプできない場合、それはユーザー体験の問題であるだけでなく、トラブルの連鎖につながり、後ろの人が長い列に並ぶことになります。これらの実際的な課題には、OceanBase が正確かつ迅速に対応する必要があります。

Yang Chuanhui 氏は、主要なビジネス システムのデータ リンクから判断すると、100 から 200 の SQL ステートメントが最も一般的なトランザクションであると述べました。異なる支払いチャネルが関係する場合、SQL 実行回数は多くなります。

Ant Financial 自体は分散システムであるため、ネットワークを含む基盤となるインフラストラクチャ コンポーネントに対する要件が非常に高いことが大きな課題となっています。

ネットワークに問題が発生すると、サービス全体に影響が及びます。したがって、OceanBase では、データベース層を最適化するだけでなく、ネットワーク、ディスク、オペレーティング システムなどのソフトウェア層とハードウェア層でも非常に正確な最適化を行う必要があります。

それで、OceanBase はこの問題をどのように解決するのでしょうか? OceanBase チームは、ビジネスの設計に最初から関与します。ビジネスでデータベースをどのように使用するか、どのように最も合理的に使用するかなどです。最初から全体的な設計に参加し、ビジネス側とアーキテクチャ全体とともに進化していきます。

Ant Financial の基本データ部門 (OceanBase チーム) の SQL グループの責任者である Jiang Zhiyong 氏は、SQL エンジンとオプティマイザーに取り組みました。彼は OceanBase 独自の SQL エンジンをゼロから構築し、特に元の MySQL アプリケーションをコードを変更せずに移行できるようにしました。

データベースの互換性に関しては、OceanBase は MySQL と互換性があります。 Ant Financial の社内業務は、変更を加えることなく MySQL データベースから OceanBase に移行できます。

オプティマイザーの観点では、関連するシステム統計情報の収集が Ant Financial のビジネス システム アーキテクチャと組み合わされ、動的および静的に分離されたアーキテクチャが設計されています。つまり、統計情報は日中はメモリに保存され、毎日ビジネスが低迷しているときにメモリからディスクに書き込まれます。

他のデータベースのようにディスクに直接書き込まないため、システム統計の収集が遅くなり、不完全になります。また、インメモリ データベースのように統計を保存するために高コストのメモリを使用することもありません。

OceanBase の準メモリ データベース設計は、SQL クエリがより包括的なシステム統計情報をリアルタイムで収集するニーズを満たすだけでなく、追加コストなしで全体的な情報収集コストを削減します。

OceanBase は、SQL ステートメントの検索最適化にも微調整を加えました。完全に自社開発のデータベースであるため、さまざまな結合クエリ アルゴリズムに柔軟に適応できます。他のデータベースでは、オプションの範囲が限られているため、より洗練された最適化を実現することは不可能です。

「検索条件の書き換えに巧妙な設計を施し、選択肢の幅を広げました。他のデータベースは、非常に狭い範囲内でしか最適な戦略を選択できないため、OceanBase の検索結果は優れています」と Jiang Zhiyong 氏は述べています。

MySQL との互換性を確保するために、OceanBase チームは MySQL を徹底的に研究し、MySQL に対して多くのチューニング作業を実行しました。

このプロセス中に、OceanBase チームは MySQL に関する数百の問題を発見し、それらは MySQL オープンソース コミュニティに報告され、確認されました。

OceanBase チームは、MySQL の使用時に、パスによって MySQL の実行結果が異なることや、MySQL のセマンティクスが不完全であるなどの問題を発見しました。

特に、アリババとアント・ファイナンシャルは事業規模が拡大し続ける中で、さまざまな技術の限界を超えるケースが多くなっています。

OceanBase チームが MySQL インターフェイス ドライバーを開発していたとき、ビジネス調査を通じて、トランザクションがロールバックされたにもかかわらず、データがデータベースに送信されたままになっているため、転送がキャンセルされたにもかかわらず、お金が転送され続けていることが判明しました。

長い調査の後、チームは最終的に MySQL クライアントの変数設定に問題があることを発見しました。ただし、この問題は極端な状況でのみ発生する可能性が高く、発生確率は低いイベントです。

OceanBase チームは、低確率のイベントを 1 つずつ排除し、最終的に汎用製品へと移行しました。

一般的な製品とシナリオベースの製品の最大の違いは、一般的な製品はほとんどのシナリオに適応できるのに対し、シナリオベースの製品は単一のシナリオにしか適応できないことです。

Ant Financial の基本データ部門 (OceanBase チーム) の設計者である Feng Ke 氏は、これが商用データベースの最大の強みであり、ほとんどのシナリオに対応できると述べています。

商用データベースのテクノロジーは最も強力ではないかもしれませんが、価格が高いにもかかわらずユーザーが依然としてそれを購入しているという事実は、商用データベースの総所有コストが低く、1 つの製品をほとんどのシナリオに適応できることを示しています。

ほとんどのシナリオに適応できるということは、考えられるほぼすべての落とし穴に遭遇したことを意味します。 OceanBase も現在、同じプロセスを経ています。

Linux にバグが発生し、チームは解散寸前

OceanBase が遭遇したもう 1 つの落とし穴は、極端な状況でのみ発生する Linux システムのバグでした。

OceanBase 自体は、Linux と C 言語をベースに開発された分散データベース システムです。 2010 年から 2011 年にかけて、OceanBase チームは Taobao のお気に入りビジネスをサポートしました。

2011 年の Double Eleven ショッピング フェスティバル中に、安定性の問題が発生しました。当時の Linux には直接 IO アクセスの機能があり、極端な条件下でのみトリガーされるバグがありました。

楊伝慧氏は、2014年の十一月まで残り1か月を切っていたことを思い出した。問題は金曜日に発生し、Taobao Favoritesが1日に3回、毎回約1時間クラッシュした。各クラッシュの後、お気に入りのトラフィックが回復されました。

アクセス数が一定数を超えると、Linux カーネルのバグが発生し、再びダウンタイムが発生しました。システムが稼働を再開したのは、金曜の夜8時か9時過ぎ、タオバオの訪問者数が減った頃だった。

当時、開発チームは主に北京に集中していたため、チームメンバー全員が翌日の土曜日早朝、北京から杭州への始発便に乗り、問題を解決した。

「当時の雰囲気は非常に緊張していました。この問題が解決されなければ、オーシャンベースチームは解散されるでしょう。」楊伝慧さんは当時の状況を振り返った。

さらに、問題を解決する際には、コードの記述を担当するプログラマーも、背後でコードの記述方法を監視する 2 ～ 3 人の人がいるため、大きなプレッシャーを感じます。

「当時は、これで問題が解決するかどうか確信が持てませんでしたが、70%～80%の確率で解決できると考えていました。そして実際に解決しました。」

「アリババ/アントファイナンシャルのシステムは急速に発展し、常に変化しています。オーシャンベースも新機能を開発し、オンラインビジネスをサポートしています。ダブルイレブンのトラフィック爆発は通常の10倍になる可能性があります。Linuxカーネルのバグなどの問題は、トラフィックが通常の1〜2倍であればまったく発生しません。トラフィックが10倍に爆発したときにのみ発生します。そのため、私たちは非常に緊張しており、問題を注意深く分析してゆっくりと解決する時間はありません。問題が発生すると、全員が残業して解決します。それだけです」とヤン・チュアンフイは語った。

挫折や失敗を通して成長する

フェン・ケ氏は、オーシャンベースに入社して最初にやったことは診断モニタリングだったと回想する。当時は、システムにデータ ポイントを埋め込むことが最も重要だったため、誰もこれを実行しようとしませんでした。

これは重要であることに誰もが同意しますが、すべてのモジュールが関係し、非常に感謝されない作業であるため、誰もそれを実行しようとしません。当時私がそれをやろうと決めた理由は、それがビジネスにとって非常に重要であり、やらなければならないことだったからです。

その過程では多くの挫折と問題がありました。たとえば、OceanBase 診断モニタリング機能が初めてリリースされたとき、モニタリングを見た N 人の人々が N 通りの異なる結論に達しました。

「この機能は、まったく使えず、作りも粗悪だと誰もが思っていたので、当時参加した学生たちは非常にフラストレーションを感じ、認められていないと感じていました。」

馮克氏は当時、チームを激励した。「他の人から最も批判されているときこそ、実は最も速く進歩しているときです。あなたの製品はより多くのリソースを獲得し、より多くの人々から認められます。これは実に素晴らしいことです。私はその時、本当に感動しました。」

OceanBase は、自ら成長し発展する機会を探しながら、ビジネスで「生計を立てる」プロセスです。 「生計を立てる」過程で、OceanBase も妥協を余儀なくされるだろう。

楊伝慧氏は、2010 年版の OceanBase には、単一ポイントの書き込み設計という大きな欠陥があったことを思い出した。

当時は、書き込まれたデータはすべて 1 台のマシンに配置されていました。このバージョンはスケーラビリティが低く、垂直方向の拡張しかできず、水平方向の拡張はできませんでした。

さらに、すべての書き込みがそのノードを通過する必要があるため、全体的なパフォーマンスが比較的低下し、データベースの機能が制限されます。

これは OceanBase の初期バージョンです。当時、チームにはデータベースの経験があまりなく、長期的な開発を行う時間もありませんでした。

2015 年に再設計・開発されたバージョン 1.0 になって初めて、真にクラウド時代に適した分散データベースとなりました。

この期間中、OceanBaseチームはさまざまなチャネルからデータベースの人材を導入し、最終的にデータベースの再構築を達成しました。

OceanBase はさらに多くの障害を経験しました。楊伝慧氏は、OceanBaseが2012年11月にAnt Financialに移管され、2014年に取引システムを実装したと振り返った。その間の2013年は、取引システムではなく、実際にはTaobaoの在庫プロジェクトに取り組んでいた。

当時、OceanBase チームは、在庫データベースの問題も大きな課題であることを認識していました。これは、本質的には在庫削減の問題である鉄道の切符販売システムの課題とまったく同じでした。2 人が同時に在庫を削減すると、すべてが混乱してしまいます。

当時、Taobao の MySQL チームもこれに取り組んでいましたが、ビジネス部門は MySQL を使用する方が快適だと感じたため、最終的に MySQL ソリューションを選択しました。

「この理由だけで、他の理由はありません。私たちは OceanBase を選択しませんでした。その年の作業はチーム全体にとって無駄でした。しかし、この基盤のおかげで、私たちは次の取引システムを実際に完成させることができました。」

R&Dの方法論: 問題を発見し、問題を定義し、問題を解決する

OceanBase の開発プロセスを要約すると、私たちは常に、Microsoft のソフトウェア開発の「3 つの柱」のような、何らかの R&D 方法論を見つけようとしています。しかし、ほとんどの場合、私たちは運用チームやビジネス チームと協力して問題を定義します。

私たちはいくつかの問題を検討し、本当の問題は何かを見つけ出し、ユーザーがその問題を定義できるように支援します。

問題を定義するときに、その問題をデータベース チームで解決すべきか、ビジネス チームで解決すべきかを分析するための会議を開催することもあります。会議の前には、最終結果がどうなるかは誰にも分からないかもしれません。私たちは多くの場合、こうした不確実なことを行っています。

OceanBase 自体は前例のない分散データベースです。チームの中心メンバーである楊振坤氏は、百度で分散技術チームを率いていた際に豊富な経験を積み、また、Googleから多くの分散技術のアイデアを吸収しました。

しかし、後に分散アーキテクチャとリレーショナル データベースを組み合わせようとしたとき、前任者の経験がなかったため、チームは独自に解決する必要がありました。

OceanBase は今のところ論文を発表しておらず、現在も事業を続けているが、Yang Chuanhui 氏は OceanBase には他社が考え付かなかった手法が数多くあると振り返った。新しい計画を考えるのに長い時間がかかり、それを実行すると決めるまでに半年から1年かかることもあります。

具体的な開発プロセスにおいて、テストは非常に重要なタスクです。分散システムにおける例外処理ではエラーが発生しやすくなります。通常、機械が故障することはありませんが、オンラインビジネス中に突然障害が発生すると、大きな障害となる可能性があります。この種の例外処理はテストが困難です。

OceanBase には災害復旧シミュレーション フレームワークがあり、マシンはいつでも停止でき、そのような災害復旧テストはいつでも実行できます。

また、並行処理テストの場合、特定の条件が満たされると、2 つのスレッドの順序や変数のアクセス順序に突然エラーが発生することがあります。 OceanBase は、このような低確率のイベントができるだけ早く発生するように、このようなシナリオを常時シミュレーションしています。

開発プロセス中、OceanBase は通常 1 人の人間によって作成され、別の人間がそのコードを読んでレビューする必要があります。承認されたコードのみが送信されます。

チームは自動テスト用のフレームワークも多数作成しました。開発者は単体テストと一部の機能テストを自分で行う必要がありますが、統合テストは専任の担当者が行います。 OceanBase にはテスターが数人しかおらず、テストのほとんどは自動的に行われます。

OceanBase はソフトウェア、ハードウェア、ビジネスを統合した全体的な最適化だからです。ソフトウェア、ハードウェア、ビジネスが融合すると、さまざまな断片化された小規模シナリオの問題が頻繁に発生します。それで、どのように解決されるのでしょうか?

陳孟孟氏は、このようなシナリオに遭遇した場合、事前に全員をグループにまとめ、そのグループに要件を投げ込むことになると紹介した。技術チームは要件に基づいてフィードバックと提案を提供し、ビジネス チームも実験で発生した問題に関するフィードバックを提供します。

これらの断片化されたシナリオと問題がソフトウェアの問題なのか、ハードウェアの問題なのか、それともビジネスの問題なのかを区別することは困難です。そのため、グループには運用、開発、ビジネス、さらにはビジネス開発を担当するBDや製品を担当するPDも含まれます。注意が必要な人は誰でもグループに参加できます。

全員がビジネスまたは技術の方向性に責任を持ち、空き時間にグループの詳細を検討します。

一部のグループは、必要に応じて人を見つけるためのものです。グループに@している場合は、これらのメッセージに必ず注目するでしょう。 @でない場合は、特に緊急でない場合はグループ内のメッセージを確認します。

グループは多数ありますが、グループメッセージを読む場合、過去数日間のすべてのメッセージを確認するのに数分しかかかりません。こうすることで、すぐに対応する必要があるものとフォローアップできるものを常に区別することができます。

通常、OceanBaseチームは午前9時から午後9時まで12時間勤務していますが、「ダブルイレブン」や「6.18」のプロモーション、春節の紅包ストレステストなどの緊急事態もあります。

もちろん、OceanBase が成長するにつれて、緊急事態に対処する必要性は減少します。陳孟孟さんは、かつては早朝までビジネスチームに同行してストレステストを行い、夜中に起こされることも多かったと回想する。

「私が経験した失敗の多くは、かなり劇的なものだったことを覚えています。なぜなら、何か問題が発生すると、あらゆる階層の人々が夜中に起こされ、グループに集められたからです。その時は誰も何が起きているのか知りませんでした。しかし、誰もが何らかの情報を持っている可能性があり、何が起こったのかを正確に把握できるように、全員が自分の情報をすぐにグループに投入しました。誰もが、自分の役割が問題を引き起こすのではないかと恐れ、少し怖がっていました。」

陳孟孟氏は次のように回想している。「障害が発生したときのことを覚えています。夜中の11時に、監督者を含む数人のグループが朝の4、5時までオンラインで問題を確認しました。最初は全員がそこにいましたが、徐々に問題がますます集中していることに気付きました。関係者が集まり、問題が解決したのは朝の4、5時になってからでした。その間、全員がグループで情報を確認し、分析し、さまざまな提案を出しました。一緒に座ったわけではありませんが、まるで部屋で一晩中会議が開かれているようでした。」

陳孟孟氏は、アリババ独自の技術ディスカッショングループの問題解決プロセスを次のように要約した。「これは、情報を絶えずフィルタリングし、分析するプロセスです。最初にすべての情報が揃っていなければ、誰もそれを要約することはできません。情報を確認した後、誰かが特定の場所に注意を払う必要があることに気づき、他の人が関連情報を追加し、ゆっくりとそれらを論理的につなげていきます。グループ内のメッセージを振り返ると、この現象は特に顕著です。最初は情報が散在していますが、徐々に合意に達し、最終的に前進することができます。」

もちろん、グループの中には、さまざまな「難解で複雑な病気」に精通した「古来の漢方医」もいます。彼らは一般的に経験豊富な人々であり、より多くの問題を経験しています。

したがって、他の人がまだ推測している場合でも、「中国の老医師」は非常に信頼できる可能性を与えるでしょう。この可能性に沿って見てみると、確かにこの角度から問題の解決策を探ることができることがわかります。

しかし、解決策を話し合った後でも、「皆、まだかなり臆病でした。コマンドは、操作とメンテナンスの責任者によって入力されました。このとき、手を安定させてミスをしないようにすることが鍵でした。ミスをすると、二次的な失敗になってしまうからです。そこで、精神的に安定した同僚を見つけて操作を任せ、誰も何も言わずに、その同僚が静かにコマンドを入力するのを見守りました。」

グループでの議論を通じて最も安全で信頼性の高い方法を選択しても、システムに直接コマンドを入力すると、データに直接影響する可能性があるためです。間違ったキーを入力すると、すべてのデータが削除され、元に戻せなくなる可能性があります。 「手術中は誰もが安堵のため息をつくことはできない。」

もちろん、各障害が解決された後、将来の解決策を見つけるためにそれを見直し、最終的に緊急計画である知識ベースを形成し、それをプログラムに固めて次のエラーを防止します。

OceanBase の機能リストは商用データベースをベンチマークしているため、OceanBase 全体には統一された製品マネージャーはいません。

ただし、通常は会計年度とダブルイレブンを重要なノードとして基にした製品開発計画は依然として存在します。たとえば、特定のバージョンは、次の Double Eleven の前に作成され、安定して実行され、Double Eleven テストに合格する必要があります。 「このリズムを維持してください」と江志勇氏は付け加えた。

将来の展望: 時間と経験、現実とのテスト

江志勇氏は、データベースの商業化には時間と経験が必要であり、投機的な精神で参加すると達成が難しいと強調した。

Ant Financial の最大の利点は、豊富なビジネス シナリオです。これにより、OceanBase は外部の顧客にサービスを提供する前に社内で十分なトレーニングを受けることができ、このトレーニングは外部ユーザーを通じて取得するのが困難です。

2017年以来、OceanBaseはAnt Financialの金融テクノロジーのオープン性に追随し、伝統的な金融を強化する実践的なプロセスを開始しました。

OceanBaseの対外事業を担当するFeng Ke氏は、「流通はOceanBaseのハイライトですが、最も重要なのは、OceanBaseが単にビジネス上の問題を解決するのではなく、製品思考に従っていることです。将来的には、対外的にも確実に発展していきます。」と述べました。

今日、OceanBase は金融グレードの分散リレーショナル データベース サービスから始めて、商用化に向けて小さな一歩を踏み出しました。

時間と現実の試練に耐えた後、チームは OceanBase をソフトウェアから一般的な製品に変えることができると確信しています。

著者: 呉寧川

紹介：「クラウドテクノロジー時代」の創始者。彼はChina Computer Newsでキャリアをスタートし、副編集長を務めました。彼は、OracleのグローバルCEO、VMWareのグローバルCEO、ARMのグローバルCEO、Amazon CloudのグローバルCTO、Microsoftのグローバルリサーチディレクター、HuaweiのCIO、JDのCTO、IBMのグレーターチャイナ会長、Alibaba CloudのCEOなど、上級幹部にインタビューしてきました。