国慶節の休暇中に、12306 のチケットを手に入れましたか? 「高速鉄道の切符は買うのが大変」「発券後なぜ待たなければならないのか」といった不満はあるものの、中国鉄道顧客サービスセンター 12306 のプラットフォームは、2011 年 6 月 12 日の開設以来、知らず知らずのうちに 13 年間を経て、高速鉄道で旅行するほとんどの乗客にとって優先されるチケット購入プラットフォームとなっています。 12306 の開発の歴史を振り返ると、それはチケット獲得ソフトウェアとの知恵と勇気の戦いを伴う「大作」であると言えます。
2024 年の建国記念日、鉄道は乗客数のピークを迎える ICPhoto
すべては12306が設立されたときから始まらなければなりません。 2011 年 6 月 12 日の最初の北京-天津都市間鉄道電子チケットの販売により、中国は鉄道網でのチケット販売を正式に開始しました。わずか数カ月のうちに、オンラインチケット販売の範囲は北京－上海、武漢－広州、鄭州－西安、その他の高速鉄道路線まで急速に拡大した。 9 月 30 日現在、全国の高速鉄道の切符 (先頭に G と D が付く) が 12306 で購入できるようになりました。2011 年末までに、全国の鉄道の切符 (先頭に Z、T、K が付く) が 12306 で購入できるようになります。わずか半年で、中国の鉄道網での切符購入は「ゼロから」から「全面的な普及」へと飛躍しました。
しかし、鉄道網で切符を購入するという斬新さは色あせておらず、2012 年の春節が静かにやって来ました。世界でも稀な大規模な移民イベントである春節は、毎年中国の運輸業界に前例のないプレッシャーをもたらしている。運送業界にとっては「大きな試練」といえる。そして、12306 年の最初のシステムクラッシュは誰もが予想を超えたものでした。
2012 年 1 月 5 日から、12306 Web サイトは 5 日連続で 10 億件以上のアクセスを受け取り、訪問数は前月比 10 倍以上に急増しました。その中で、1 月 9 日のアクセス数は 14 億件を超え、世界で最もアクセス数の多い Web サイトの 1 つになりました。2011 年末時点で中国のインターネット ユーザーはわずか 5 億人だったことをご存知でしょう。
このようなアクセス圧力は、プラットフォームの建設当初には考慮されていませんでした。 12306 システムの構築の開始時に、開発者は、乗車券のコア システム アーキテクチャとインターネット アプリケーションの特性に基づいて、キャッシング サービス、ユーザー管理、チケット照会、注文および電子チケット処理などのシステム用の複数の比較的独立したビジネス パーティションと、3 レベルのネットワーク セキュリティ ドメイン、つまり外部ネットワーク、イントラネット、および乗車券ネットワークを設計しました。オンライン化前のストレステストでは、ユーザーのログイン、チケットの照会、注文、支払いがプロセスに含まれていました。システムの最大トランザクション容量は 34 チケット/秒でした。ピーク期間の 10 時間に基づいて計算すると、チケット販売量は 1 日あたり 120 万枚の設計容量に達する可能性があります。
しかし、ストレステストでは、チケット取得ソフトウェアである「招かれざる客」を見逃した。チケット取得ソフトウェアは、マシンの迅速な応答を利用して、ユーザーがページを絶えずクエリして更新するアクションを完了できるようにするブラウザ ベースのプラグインです。列車の残りのチケットを高頻度で照会し、個人情報を自動的に入力し、複数のアカウントを同時に操作することで、手動でチケットを購入するユーザーよりも早くチケットの購入プロセスを完了します。
プラットフォーム上で「チケットがない」という事態に苦しむ乗客は、すべての安全を確保するために、お金を出してチケット取得ソフトウェアに助けを求めるしかありません。
チケット取得ソフトウェアによって引き起こされる膨大なトラフィックを十分に見積もっていなかったために、12306 は多数のチケット取得ソフトウェアに対して脆弱でした。12306 の Web サイトは麻痺し、多数のユーザーがログインできなくなり、ページの更新に最大 30 分かかりました。予約して支払いをした後、チケットを購入できませんでした。多くのチケット購入者は、12306 ウェブサイトを「名ばかり」となす術なく非難した。
しかし、後戻りはできないため、12306 チケット発行チームは戦うしかありませんでした。帯域幅不足の問題に対応して、12306 チケット発行チームは即座に決断を下し、すぐに帯域幅を 600 MB から 1000 MB に増加し、すぐに 1500 MB に増加しました。チケット販売チームは、オンライン チケット販売データを監視および分析した結果、オンラインで大量のチケットを購入したユーザーは非常に少なく、1 日に購入されたチケットの総数が 100 枚を超えていることを発見しました。公平なチケット購入を確保するために、12306 チケット販売チームは 1 月 5 日からオンライン チケット購入プロセスを調整しました。ユーザーがチケットを正常に購入すると、システムはユーザーを強制的にログアウトし、再度チケットを購入する場合は再度ログインする必要があります。
旧鉄道省も「海外援助」の誘致を考えていた。当時、Webサイトの中で「短期間にアクセスが急増しても潰れなかった」経験が豊富だったのは、「ダブルイレブン」で盛り上がっていた天猫と淘宝（タオバオ）だけだった。そのため、アリババ グループは 17 人の技術エリートを派遣してプロジェクト チームを結成し、12306 ウェブサイトの最適化と改善を支援しました。 2 つのチームは協力して、12306 Web サイトのユーザー エクスペリエンスを大幅に向上させました。このシステムによる1日のチケット販売数は1月初旬の65万枚から100万枚以上に増加し、1月20日には1日のチケット販売数119万2000枚という記録を樹立した。
天猫淘宝モールの「ダブル 11 グローバル ショッピング カーニバル」の広告が上海徐家匯駅を独占し、利用客の獲得を競う ICPhoto
発売から 1 年も経たないうちに春節旅行のこの「極端なテスト」が行われた後、12306 アーキテクチャに関する議論や論争がインターネット上にも現れました。当時の鉄道省は関係者の意見を十分に聞き、問題の原因を慎重に整理し、主に乗車券の問い合わせと予約が原因であると結論づけた。シングル/電子チケット業務パーティションの処理能力が不足しているため、ピーク時の同時アクセス要求が多いと応答時間が長くなります。さらに、各ビジネス パーティションを十分に分離できないため、システムの内部から外部への「雪崩」効果が発生し、Web サイトの混雑が発生し、ユーザーのチケット購入エクスペリエンスに影響を与えます。
上記の問題と理由に対応して、開発者は、チケット照会とトランザクション処理の応答速度の向上、バックエンド システムのスケーラビリティの向上、オンライン キューイング方法の変更、およびピーク時の集中チケット リリースによって引き起こされる帯域幅の圧迫を軽減するためのアーキテクチャの最適化と再構築のアイデアに焦点を当てました。同時に、中核事業を可能な限り分離して、ビジネスリンク間の強い相関関係を減らします。具体的な内容としては以下のようなものが挙げられます。
まず第一に、同時クエリ機能を大幅に改善する必要があります。 12306 は、従来のデータベースの代わりにインメモリ コンピューティング データベースを使用し、チケット クエリの応答速度を 1,000 回/秒未満から 20,000 回/秒以上に向上させ、応答時間を当初の 1 秒から 10 ミリ秒に短縮することで、ユーザーが列車番号と残りのチケットを迅速に取得できるようにします。
2つ目は、繁忙期に「混雑せずに注文の列に並ぶ」ことです。この目的のために、12306 はトランザクション処理キュー システムを構築しました。キューの注文リクエスト受信能力は 1 秒あたり 100,000 注文を超えています。ユーザーは、チケット販売のピーク時に注文操作を迅速に完了し、システムが順番に処理するのを待つことができます。処理待ち中に、キューイング状況（処理待ち時間）を問い合わせることができます。インメモリ コンピューティング データベースは、キュー システムでも使用されます。
3 番目に、注文/電子チケットはノード、データベース、テーブルに変換され、元の 1 つのノード、1 つのデータベース、および 1 つのテーブルが 3 つのノード、30 のデータベース、および 30 のテーブルに分割されます。オンライン関連の操作は各ノードとデータベース テーブルに分散されます。このようにして、Web サイトでのユーザーのチケット予約リクエストに迅速に応答し、処理できるようになります。
最後に、チケット予約とチケット回収業務のビジネス分離が実行され、異なるビジネス ノード (チケット販売ノードとチケット回収ノード) がオンライン チケット販売とオフライン チケット回収サービスを実行します。注文/電子チケットの生成とクエリの読み取りと書き込みは分離されており、メモリ内コンピューティング データベースを使用して注文/電子チケットを一元的に保存します。注文クエリの応答速度が約200回/秒から5000回/秒以上に向上し、注文/電子チケットのクエリ効率が大幅に向上します。
オンライン化前のストレステストでは、アーキテクチャを最適化した後のシステムは、1日あたり500万枚のチケット販売量のビジネスニーズに対応できる最大トランザクション容量300チケット/秒を達成した。 2013 年の春節期間中、構造の最適化後の 12306 ウェブサイトの 1 日あたりの最高チケット販売数は 364 万枚に達し、チケット総販売数の 40% を占めました。チケットの売り上げは2012年の春節のピーク時（119万枚）の3倍以上となった。
2013年2月14日、安徽省の淮北駅で帰りを待つ親子たち。 ICフォト
ただし、12306 プラットフォームの需要は依然として急速に増大しており、当初の改良はすぐに限界に達しつつあります。 2013 年の国慶節ゴールデン ウィークには、12,306 枚のインターネット チケット販売が 460 万枚に達し、再びシステム処理の上限に近づきました。さらに、3G ネットワークの限界 (4G ネットワークは初年度でしたがまだ普及していませんでした) とインターネット ユーザー数の急速な増加により、ピーク時に外部ネットワークの入り口の帯域幅が逼迫し、インターネット チケット販売のさらなる増加のニーズを満たすことができなくなりました。さらに、鉄道切符販売の主要チャネルであるインターネット発券システムの単一センター運用モデルでは、ビジネスのセキュリティと信頼性のニーズを満たすことができなくなりました。
この目的を達成するために、2013 年末から 12306 Web サイトの構造最適化の第 2 ラウンドが開始されました。
ユーザーログインや頻繁に使用する連絡先問い合わせなどのサービスをメモリデータベースに移行し、関連サービスの処理性能と信頼性を向上します。
鉄道科学アカデミーの第 2 生産センターは、中国国鉄グループ有限公司の既存の第 1 生産センターとの「ダブルアクティブ」を実現するために建設され、ウェブサイトのセキュリティと信頼性を向上させ、注文/電子チケットクラスターの処理能力を 2 倍にしました。注文/電子チケット クラスターは、10 グループのノード、100 のライブラリ、および 100 のテーブルに拡張されました。
チケット照会サービスをパブリッククラウド上に導入します。ポリシー構成を通じて、チケット照会トラフィックをいつでもパブリック クラウドに転送して、チケット販売のピーク時の Web サイトの処理リソースと帯域幅への負担を軽減できます。
オンライン化前のストレステストでは、システムが 1 日あたり 1,000 万枚という設計上のチケット販売能力を満たせることが確認されました。 2015 年の春節旅行のピーク時には、実際のチケット販売速度は 1 秒あたり 1,000 枚 (1 時間あたり約 360 万枚) を超えました。 2015 年の春節期間中、パブリック クラウドはクエリ リクエストの最大 75% を迂回させ、Web サイトの外部チケット クエリ サービスの容量は 3 倍に増加しました。 12306 Web サイトは、2015 年の春節旅行のピーク時期に 180 億件以上のチケット照会サービスを処理し、平均応答速度は 30 万回/秒以上でした。
春節旅行の「極度のプレッシャー」に対する 12306 の耐荷重が 2 倍になるにつれ、かつては設計チームと運用チームの頭痛の種だった「切符を掴むプラグイン」が、不安定性の最大の要因となっています。 12306 チームは、チケット購入時にチケット取得ソフトウェアを使用することに繰り返し抗議してきましたが、インターネット上には依然としてチケット情報を自動かつ頻繁に更新し、チケットを取得するためのレポートを自動的に入力する小さなソフトウェアが無数に存在します。このタイプのソフトウェアは、チケット情報を迅速に更新することでチケット取得の成功率を向上させ、ユーザーができるだけ早くチケットを取得できるようにすることを目的としています。これは市場の需要には応えますが、手動でチケットを購入する一般の人々に重大な干渉を与え、チケット購入の公平性に影響を与えます。成功率を高めるために、ユーザーは事前に乗客の個人情報をシステムに入力する必要があることがよくあります。 「チケットを掴む」という不安の中で、自ら個人情報を漏らしてしまいます。
このような背景から、12306 チームは的を絞った変更も行う必要があります。システムのピーク処理能力を継続的に最適化することに加えて、実名システム、複雑な認証コード、携帯電話認証コード、その他の機能も導入しました。しかし、それでもチケット取得ソフトの横行を抑えることはできず、その結果、春節と国慶節のゴールデンウイーク期間中にネットワークチケットの購入がうまくいかないという現象が発生した。
2019年の春節まで、12306は順番待ちチケット購入サービス機能を試験的に運用した。この機能は、手動のユーザー注文とチケット取得ソフトウェアのユーザー注文を同じ「賞金プール」に入れて、誰もが公平に競争できるようにし、システムがランダムに「勝者」を選択して、その後のチケット購入プロセスを完了します。このように、画面の更新がどれほど速くても、チケット取得ソフトウェアには何のメリットもありません。これにより、チケット取得ソフトウェアの人気は徐々に抑制されていきます。
ことわざにあるように、「悪魔も道と同じくらい優れている」。待機リストのチケット モデルは、チケット取得ソフトウェアに対して 12306 にとって大きな打撃です。しかし、利益に動かされて、チケット取得ソフトウェアは、待機リストのチケット賞金プールでのチケット取得ソフトウェアの注文の「当選確率」を高めるなど、このモデルに対して不公平な競争を続けることは間違いありません。私たちの 12306 チームは困難を克服し、世界最大の訪問数と取引数を誇る発券システムを維持できると信じています。発展を続ける中国の鉄道網と住民の旅行ニーズに合わせて、両者の知恵と勇気の戦いは今も進化している。