いや、チェックポイント、知らないわけじゃないんですよ。ただ、ちょっと曖昧というか、ぼんやりというか、いや春ですしね、ちょっとボーっとしたくなる時期じゃないですか。じゃあ続きはいつものように、長江先生にお願いすることにしましょう！
「チェックポイント」の重要性についてあらためておさらいしますよ
吉村 ミッションクリティカルなデータベースを構築する上では、ときには「チェックポイント」のチューニングが重要な鍵を握るという噂をちらりと耳にしました。
長江 そんなマニアックな噂、どこで流れているんですか？
吉村 ミッションクリティカル界隈ですね。
長江 ミッションクリティカル界隈。
吉村 噂の真相を確かめるべく、今回はチェックポイントについてご教示いただきたく。
長江 拝承。簡単に説明すると、こういうことです。DBMSがアプリケーションから受け取ったデータ更新処理は、すぐその場で処理されるわけではなくて、メモリ上にいったん溜め込まれた後に処理されます。この「更新処理が実際にディスク上に反映されるタイミング」のことをチェックポイントと呼びます。高トランザクションなシステムでは、アプリケーションが更新処理をコミットするたびにディスクにアクセスしていては、膨大な量のディスクI/Oが発生してパフォーマンスがガタ落ちしてしまいます。そこで、一度メモリ上に更新内容を溜め込んで、ある程度溜まった時点でまとめてI/Oを発行することで、ディスクI/Oのボトルネックを減らそうというわけです。
吉村 なるほどなるほど。ちなみにそれが、なんでミッションクリティカルなシステムでは大事になるんでしょう？ そもそも、こんなデータベース内部のディープな話、知らなくったって何とかなりません？
長江 何とかなります。
吉村 ―以上―。ごきげんよう！
長江 そうだ、大事なことを言い忘れました。「よほど厳しい要件でなければ」何とかなります。
吉村 ……と言いますと？
長江 正確に言うなら、HiRDBの場合だとデフォルト設定のままでも大抵のミッションクリティカルシステムの要件はクリアできます。しかし「極めて厳しい要件」、特に障害時の復旧時間（RTO）の要件が厳しいケースでは、チェックポイントの仕様をきちんと把握してその設定をチューニングする必要性が出てくるかもしれません。
吉村 だんだん話に付いていけなくなってきたので、ここでいったん仮眠をとらせていただきたく。
長江 仮眠しなくても大丈夫です。チェックポイントの仕組み自体は、決して難しいものではありません。チェックポイントが走って、ディスクにデータが書き込まれた時点で、データの一貫性が担保されることは分かりますよね？
吉村 スヤスヤスヤ……
長江 寝ちゃダメー。いいですか、障害が発生してデータベースがダウンしてしまった場合、最後のチェックポイントからダウンした時点までの間に発生した更新処理は、トランザクションログには記録されているものの、ディスクにはまだ反映されていません。そこで、データベース再起動時にトランザクションログからその内容が読み込まれて、トランザクションがコミットされているものはあらためて更新処理を行い（ロールフォワード）、トランザクションが未完のものは破棄されるわけです（ロールバック）。
吉村 むく。何となく分かってきました！そこでロールフォワードするトランザクションの量が少なければ少ないほど、復旧が早くなるわけですね。ということは、チェックポイントを普段からこまめにやっておけば、ディスクにまだ反映されていない更新処理の数は常に少ないので、万が一の障害時にも早く復旧できると……スヤスヤスヤスヤ……
長江 だいたい合ってるので寝ないで。HiRDBは、データベースの復旧を数十秒以内に行うといったかなり高いRTO要件にもデフォルト設定のまま応えられるんですが、世の中には「障害時のデータベース復旧を10秒以内で！」といったようなとんでもなく厳しい要件が求められるシステムもあるんです。金融系のオンラインシステムなんて、その典型ですね。そんな場合でも、HiRDBではチェックポイントの頻度を高めるようチューニングすることで確実に対応できるようになっています。
「ミッションクリティカルな回転寿司店」でもチェックポイントが大事！
吉村 ヘイらっしゃい！
長江 寝言……？
吉村 いえいえ、つまり、こういうことですね。もし1分間に1万皿ぐらい出すミッションクリティカルな回転寿司店があったとしましょう。次から次へと押し寄せるお客さんをなるべく早くさばかないと、お店が回りません。そのためには、お客さんが食べたお皿を会計のときにまとめて数えていては、とてもじゃないけどさばききれない。でも、お客さんが食べてる最中に店員が随時お皿を回収して、その枚数を数えていれば、最後の会計もさっと済むわけじゃないですか、そうでしょう!!
長江 それは微妙……。だって、食べてる途中でお皿の数を数えるっておかしくないですか？
吉村 なにせミッションクリティカルな寿司店ですから、お客さんが食べる量も半端じゃないんですよ。あっという間に皿がうず高く積まれちゃうんです。だから、店員さんがデータベースのチェックポイントのように、定期的にお皿を回収して回らないと、もしお寿司を運ぶレーンが故障しちゃって、お客さんに別のレーンに移動してもらわないといけなくなったとき、それまで食べた皿の数をその時点でいちいち数え上げてたら、いつまで経っても移動できないじゃないですか、ちがいますか？
ミッションクリティカル回転寿司のイメージ（作画：八王子ヒロミ）
長江 完全にたとえに引きずられているような気がするけど……まあ、データベースのチェックポイントの仕組みも、そんな感じだと理解してもらっていいでしょう。でも、単にチェックポイントの間隔を短くすればいいというわけでもないんです。そうすれば、確かに復旧時間は早くなりますが、その代償としてオンライン処理の性能に悪影響を及ぼす可能性があるんです。
吉村 1分間に1万皿って、すごいですよ。あまりに高速に回転するものだから、半周した時点でネタがもう原型をとどめてないんです。
長江 それは困ります。……ええと、チェックポイントが頻繁に発生するということは、更新処理をあまりメモリ上に溜め込まずに頻繁にディスクに書き込むということですから、その分データベースのリソースを消費して、オンライン処理の性能が劣化する可能性があるんです。なので、性能を重視する場合にはむしろチェックポイントの間隔は広くとった方が有利だといえます。
吉村 つまり、トレードオフということですね。
長江 そういうことです。まとめると、チェックポイントの間隔を広く取ればオンライン性能は上がりますが、障害時の復旧時間は伸びます。逆に間隔を狭く設定すれば、オンライン処理の性能劣化のリスクがありますが、その代わり復旧時間は短くおさえられます。ミッションクリティカルなデータベースでは、システム全体の性能と復旧時間の要件をしっかり把握した上で、この両者のバランスをしっかり見極めてチェックポイントのチューニングを行う必要があります。ちなみにHiRDBは、この点においてもかなり柔軟な設定ができるんですよ。
吉村 というと？
長江 たとえば、チェックポイント処理をある程度前倒しして行ったり、複数のプロセスで並列処理するなどして、オンライン処理に及ぼす悪影響を抑えられるようになっているんです。かなりディープな機能になりますけど、この辺りのチューニングを突っ込んで行うことで、性能と復旧時間の両方をかなり高いレベルで両立できるのがHiRDBの特徴なんです。
吉村 つまり、ミッションクリティカルな回転寿司店でいうと……
長江 それ、まだ続けますか。
吉村 お皿の回収とカウントを複数の店員さんで手分けして行うことで、お客さんに対するサービス品質をなるべく落とさないようにするということですね。
長江 もはや、そのたとえが適切なのかどうかさっぱり分かりません。
吉村 なんせミッションクリティカルな回転寿司ですから、客層もレベルが高いわけです。1家族で500皿ぐらいは平気で平らげますから、もたもたしてるとあっという間に皿が天井まで積みあがっちゃうんです。
長江 そうですね。
吉村 そんな危険な状況下で、和気あいあいの家族団らんなんてできるわけないじゃないですか。
長江 そうですね。
吉村 あちこちで皿の山が崩れて阿鼻叫喚の流血騒ぎに！
長江 そうですね。
吉村 拝復。
長江 ちょっと不安が残りますが、だいたいわかっていただけたようなので、今日はここまで！
吉村 チェックポイント、拝承！多謝！
