業務支援データベースの高速化のカギは発想の転換　アットホームの実践例：データベース高速化のいま（2）（2/2 ページ）

» 2015年09月18日 21時25分公開

基幹業務データの活用がデータベースパフォーマンスの不満に

　同社では5年ほど前から基幹業務システムのデータベース情報を営業部門向けに提供している。もともと、「基幹業務システムのデータベースは営業部門での情報参照を許可しない」というポリシーで運用していたのだが、「基幹業務システムのデータベースが持つ情報を参照し、営業活動に利用したい」という社内の要望に対応した形だ。

アットホーム情報システム部管理運用グループ宮之原秀雄氏

　具体的には、「簡易な情報参照システム」として、基幹業務システムのデータベースから前日までのデータを別の参照用データベースに複製し、そこで営業部門側が自由にデータを分析できるようにしたという。

　当初、一部の社員のみが利用していたのだが、徐々に利用者が増え、参照データベースのアクセスが増加。加えて、個々の利用者が分析したデータも同じデータベースに格納していたことから、データ量も増していった。結果、利用者からは「データ抽出が遅い」といった声が上がるようになっていった。

　「もともとは参照できなかった情報が閲覧できるようになったことから、個々の社員が自分のアイデアで多様なデータ分析を行うようになった。分析データが実際に業務に役立ったことから、徐々にパフォーマンスの問題が大きな課題となっていった」（宮之原氏）

簡易な情報参照システムを本格的な高パフォーマンスシステムに

　これをきっかけに、まずは「簡易な情報参照システム」であった営業部門向けのデータベースに対して、本格的にパラメーターやSQLのチューニング、クエリ並列化などでパフォーマンス改善に取り組んだという。データベースソフトウエアライセンスの見直しも行い、Oracle DatabaseのEnterprise Editionを採用、並列化オプション機能を利用することにした。

当初の「簡易な情報参照システム」　データ量の増加、アクセスユーザーの拡大に対応するため、当初はソフトウエア面でのチューニングを実施した（宮之原氏の講演資料より引用）

　それでも、当初の対応は「つぎはぎだらけ」。アクセス集中については、さらに個別に限定的なテーブルを用意して提供するなどの暫定的な対処を進めたが、限界が近づいていたという。

　本稿冒頭で示したように、各データベースシステムとも性能改善を目的に、各種フラッシュストレージの検討を進めていたが、この情報参照システムではオールフラッシュストレージ適用によるパフォーマンス改善とコスト削減を狙ったという。

　現在は、2台のPCサーバーを使い、データベースは「Oracle Database 12c Standard Edition」を採用。8Gビットイーサネットでオールフラッシュストレージに接続する構成で運用しているという（2台のサーバー自体はファイバチャネルで直接接続。参照系なのでバックアップは考慮していない）。

　ここで、「ソフトウエアの並列処理」ではなく、フラッシュストレージを選択することで「ストレージI/Oパフォーマンス向上によるデータベースシステム全体のパフォーマンス改善」に発想を切り替えた。これにより、「Enterprise Editionでなくても運用できるようになったことから、並列処理のために購入していたライセンスコスト削減を実現」（宮之原氏）したという。「発想の転換」によってコスト削減を実現したといえるだろう。

　もちろん、パフォーマンス改善とコスト削減を両立する方法はこの限りではない。事実、Enterprise Editionには、「データ分析基盤との連携機能」や「運用管理を効率化する機能」など、有用なオプションも多数あるため、Enterprise Editionの方がマッチする場合も当然あるだろう。だが、“このケースでは”Enterprise Editionよりも目的に適合する選択肢があった――つまり、製品選択は機能ではなく目的起点で考えるべきということだ。

　同社はこの他のシステムでも、その特性に合わせてフラッシュストレージを適用したデータベースシステム改善を行っている。

　例えば、MySQLで稼働するシステムでは「ioDrive2」を導入。アクセスログのマスター／スレーブデータ（兼バックアップ）の格納に利用している。導入が容易であり、ランダムな読み込み／書き込みに強い点を評価しているという。

　また、MongoDBで構築した不動産物件情報「ATBB」のシステムではメモリスロットに挿して利用できるフラッシュストレージ「eXFlash DIMM」を採用。物理サーバー3台で「Oracle Database 11g R2」のRAC構成で運用していたシステムを、「VMware vSphere」による仮想環境上のMongoDBで運用する形態に切り替えている。eXFlash DIMMはブロックストレージとして扱える上、PCIeフラッシュストレージよりも低コストで、枚数を増やせばスケールする点を評価しているという（3台のサーバーそれぞれで3枚ずつeXFlash DIMMを搭載している）。

選定時にチェックした運用工数削減のポイント

　宮之原氏は、フラッシュ製品を選択する中で重視したポイントとして、ストレージ単体で「完全冗長化を実現していること」、運用の工数を考え「ホットスワップに対応していること」を挙げる。

　特にホットスワップに対応していない場合、「メンテナンスのたびにシステムのシャットダウンと立ち上げが必要になることから、運用面での負担が大きくなるため、避けたいポイントだった」という。この他、ゾーニング設計や管理画面習得など、導入後の運用管理工数が増えないことも重視している。

　また、「導入が容易な製品であったとしても、あらかじめストレージのフォーマット比率を考慮しなければ、ガベージコレクションの影響を受け、一日当たりに書き込めるデータ量に制限が発生したり、レイテンシが発生したりするケースがある」といった、実運用経験者ならではの見解も聞くことができた。

*注：ガベージコレクションの問題については記事「フラッシュストレージで、このデータベースは速くなる？ならない？」でも紹介している。

　宮之原氏は、講演の終わりに「選定時には、ガベージコレクションの挙動を見込んだフォーマットを検討するなど、製品ごとに異なる特性への理解が重要。また、安定した運用を目指すには、過去のファームウエアのアップデート履歴や故障率も調査するべきだ」と注意を促した。

　本稿では、アットホームにおけるデータベース高速化の取り組みと経験則を紹介した。データベースシステムの性能を高めることはもちろんだが、同社が導入のポイントとして挙げたのは、導入後のシステム運用プロセスの改善も重視した選定だ。

　初期のフラッシュストレージ製品の中には、圧倒的なI/O性能を誇る一方で、実運用でのデメリットを持つものも少なくなかった。しかし、一定の普及が進んだ現在では、ユーザーの声を受けたファームウエア改善などで従来のデメリットを払拭（ふっしょく）し、使い勝手を向上させている製品も少なくない。特に運用面での評価は、最新のユーザーレビューをリサーチしておくことで選択肢の幅が広がることだろう。

「データベース高速化のいま」バックナンバー