【ITニュース解説】法改正に伴うデータベース性能改善への挑戦--NTTドコモビジネスの取り組み

NTTドコモビジネスが直面したデータベースの性能改善に関する挑戦は、システムエンジニアを目指す皆さんにとって、システムがどのように作られ、改善されていくかを理解する上で非常に良い事例だ。ある日突然、法改正という外部からの要請によって、既存のシステムが大きな変更を迫られることがある。NTTドコモビジネスの場合、携帯電話不正利用防止法の改正がそのきっかけとなった。

この法改正により、携帯電話の契約時における本人確認がこれまで以上に厳格になった。具体的には、本人確認の方法が従来の対面での確認に加え、オンラインでの生体認証や、本人確認書類の画像をアップロードする方法が一般的になるなど、多様化・高度化した。この変更は、契約手続きを行う顧客の利便性を高める一方で、システム側には大きな負荷をかけることになる。特に、本人確認に関する情報を管理するデータベースへのアクセスが急増することが予想された。

NTTドコモビジネスは、このアクセス急増によってデータベースの性能が劣化し、システム全体の応答速度が遅くなることを懸念した。もしそうなれば、顧客が契約手続きに時間がかかりすぎると感じたり、最悪の場合、システムがダウンしてサービスが提供できなくなったりする可能性もある。これは企業にとって避けなければならない事態だ。

既存のシステムは、長年の運用を経て構築されてきたものであり、当時の要件に合わせて最適化されていた。しかし、新しい法改正や、生体認証・画像認証といった新しい認証方式への対応は想定されていなかったため、いくつかの課題を抱えていた。その一つは、データベースのデータ構造が複雑だったことだ。複数の認証方式に対応するために、多くの情報が一つのテーブルに詰め込まれており、特定の情報を探すのに時間がかかったり、データの更新時に不要な部分までロックがかかってしまったりする可能性があった。

ここでいう「ロック」とは、データベース内のデータが同時に複数の処理から変更されるのを防ぐための仕組みだ。例えば、ある人が口座からお金を引き出している最中に、別の人が同じ口座にお金を入金しようとした場合、同時に処理すると残高が正しく計算されない可能性がある。そのため、データベースは一時的にそのデータに「鍵」をかけ、他の処理が完了するまで待たせる。しかし、このロックが不要な場所にかかってしまうと、他の処理が待たされる時間が長くなり、システム全体の処理速度が落ちてしまうのだ。特に、生体認証と本人確認書類の画像認証では、データの種類や処理の特性が大きく異なるにもかかわらず、同じテーブル内で扱われていたため、互いの処理が干渉し合うリスクがあった。

この問題を解決するため、NTTドコモビジネスが最初に行ったのが、データベースの「分割」だった。具体的には、生体認証に関するデータと、本人確認書類の画像認証に関するデータを、それぞれ別のテーブルに分けるという大胆な変更を決断した。これにより、それぞれの認証方式が独立して処理できるようになり、お互いの処理が干渉し合ってロックがかかる、といった問題を根本から解決できた。例えるなら、これまで一つの広い部屋で複数の作業者が混雑しながら作業していたのを、それぞれの作業内容に合わせて専用の部屋を用意し、作業効率を上げたようなイメージだ。

さらに、データ構造の最適化も行った。生体認証では、個人の生体情報そのものをデータベースに保存するのではなく、その情報を特定のルールで変換した「ハッシュ値」と呼ばれるデータを保存することにした。ハッシュ値は、元の情報からは元の情報を推測できないように変換された、一方向の計算結果だ。これにより、もしデータベースが不正アクセスを受けたとしても、個人の生体情報そのものが漏洩するリスクを低減できる。また、本人確認書類の画像データは非常に容量が大きいため、データベースに直接保存するのではなく、別の専用のストレージに保存し、データベースにはその画像への参照情報（どこに保存されているかを示す情報）だけを保持するようにした。こうすることで、データベース自体の肥大化を防ぎ、アクセス速度を維持することが可能になった。

データベースの性能を向上させる上で欠かせないのが「インデックスの最適化」と「SQLチューニング」だ。インデックスは、データベースに保存された大量のデータの中から、必要な情報を素早く見つけ出すための「索引」のようなものだ。書籍の巻末にある索引と同じで、これを適切に設定することで、データの検索速度が劇的に向上する。どの列にインデックスを付けるべきか、複数の列を組み合わせた複合インデックスが必要かなど、データの使われ方に応じて最適なインデックスを設計することが求められた。

そして「SQLチューニング」とは、データベースに命令を出す「SQL文」の内容をより効率的なものに改善することだ。SQL文は、データベースからデータを取得したり、更新したりするための命令だが、書き方次第で処理速度に大きな差が出る。例えば、同じ目的の情報を取得する場合でも、非効率なSQL文を使えば何百倍も時間がかかることがある。NTTドコモビジネスは、システムがデータベースに送るSQL文を一つ一つ見直し、最適な形に改善することで、処理速度の向上を図った。

これらの取り組みは、物理的なサーバーの性能を上げる（CPUを増やす、メモリを増やすなど）だけではなく、ソフトウェアやデータの構造を根本から見直すことで、既存のリソースを最大限に活用し、さらに性能を向上させるという、システムエンジニアとして非常に重要な視点を示している。限られた時間とリソースの中で、法改正という急務に対応するため、同社はアジャイル開発のようなスピーディなアプローチで改善を進めた。これは、要件変更に柔軟に対応し、短いサイクルで開発とテストを繰り返しながら品質を高めていく手法だ。

この事例は、単にデータベースが速くなったという話で終わらない。システムは常に変化する外部環境、特に法改正のような予測できない大きな変化に対応していく必要があることを教えてくれる。そして、その変化に適応するためには、既存のシステムの構造を理解し、技術的な知識を駆使して、根本的な問題解決に取り組む能力がシステムエンジニアには求められる。データ構造の設計、データベースの分割、インデックスの最適化、SQLチューニングといった技術は、これからのシステム開発において、避けては通れない基本的なスキルであり、常に磨き続ける必要があるのだ。NTTドコモビジネスの挑戦は、複雑な現代のITシステムを支えるエンジニアの仕事の面白さと難しさ、そして社会への貢献の大きさを明確に示している。