（登壇者）
- 日本オラクル：小田圭二氏
- アシスト：関俊洋氏
- DB Onlineチーフキュレーター：谷川耕一氏
チューニングのスキルとは
谷川：2つ目のテーマとして、DBのエンジニアの専門性スキルっていうのをどう捉えていけばいいのか。チューニングっていうのはたぶん大きなテーマのひとつだと思います。チューニング、簡単にチューニングって言いますけど、どんなスキルを身につけていけばいいのか。まず関さんにうかがってもいいですか？
関：チューニングで一番大切なことって目標を決めることなんですよね。どこまで満たせればチューニング終わりっていうのが決められるかどうかがすごく大事。たとえば「遅い」って言われて「すみません、そこ直しますね」っていうやり取りだけだと、終わりが見えない。どこまで修正したらそれが終わりなんですか？っていう、ゴールをきちんと確認して、アプローチを立てられるかどうかっていうところですよね。それが1つ目。あとは手段をどうするか。SQLでなんとかしましょうっていうだけがチューニングじゃないので、あらゆる手段を考えられるかどうか、計画っていうのを立てていく必要がある。だからチューニングって、いろいろあるなっていうところがまず、入口かなと思いますね。
谷川：同じ質問になりますけども、チューニングについて、Oracleコンサル的にはどう捉えていますか？
小田：チューニングは、今後もなくならないと思っている1つの領域です。この後、話題になると思うんですけど、クラウドや自動化もあるじゃないですか。そういう、ある程度はチューニングしなくていい世界というのも出てくるとは思います。ただ、その一方で、チューニングだけはですね、どうしても匠の技というか、エンジニアのハイスキルが必要なとこです。なぜ必要かって言うと、なんだかんだでITは利便性を上げるためにブラックボックス化とか、隠蔽化するじゃないですか。チューニングだけはどうしても内部を見なきゃいけないのです。内部構造を見て、アルゴリズムや動きを理解した上で性能を出さなきゃいけないので、ここだけはあと10年経とうが20年経とうが、一部のシステムに関しては絶対になくならない仕事だろうなと思っています。
谷川： SQLチューニングっていうお話と、先程ちょっと話題に出ていた、インフラ側、インスタンスのチューニングについて。これは、どう捉えればいいでしょうか？
小田：わかりやすいところで言うとメモリですね。メモリのいろんなパラメーターがOracleにもありますし、OracleじゃないDBにもあると思うんですけど、そこをどう設定するのか。あとは自動化もありますが、メモリのチューニングを自動化するのも良し悪しがあるので、そこをどうガバナンスを効かせるか。さらにメモリがいったいどこに関係してくるかと言うと、ユーザー数だとかセッションとかがメモリに影響を与えたりもするんですね。それだけじゃなくて、DBの中って競合、よく言うロックもあります。そういうところにも競合してきたりする。いろんな内部の複雑な動きとそれに伴って何かがぶつかるとか、トレードオフがある。そういったところを解消してくのがインフラのチューニングの観点になります。SQLのチューニングとは、また全然、違うアプローチになりますね。
谷川：関さんのところは、ODAを扱うとか、ハードウェア屋になったっていうお話がありましたけど、そこら辺からやっぱり大きく変わってきたチューニング手法っていう感じですか？
関：そうですね。今、パラメーターの例が出ましたけども、運用が始まってからトラブった時って、「パラメーターってなんでこれにしたんだっけ？」っていう風になりますよね。で、たぶん運用とアプリってすごく仲が悪くて、「なんでこんなパラメーターにしたの？っていうドキュメンテーションを送れ」って開発側に言うと、パラメーターの設定値は書いてあるんですけど設定理由は書いてないとかですね。たぶんあるんですよ。チューニングの時は、そこがきちんと論理立てて説明できなきゃいけなくって、「こういう値にします。それは何々だからです」っていうところにもっていけるかどうかですよね。それにはたぶん開発と運用、インフラのコミュニケーションが必要だし、それを最終的な答えに持っていくという力も必要だし、という意味で、チューニングってすごい難易度が高いし、今後もそういう意味ではなくならないんじゃないかなと、私も同じ意見ですね。
谷川：ちなみにちょっと興味で聞くだけですけど、ExadataとかODAとかけっこうメモリー系とかインフラ周りのインスタンス系のチューニングをするものなのですか？
関：ベストプラクティスはあるんですよ。Oracleさんが作ってる「これです」っていうのはあるんですけど、それを使う場合と使わない場合がある。必ずしもベストプラクティス通りやっていただけるわけじゃないので。なせかというと、ExadataとかODAをご利用されるシステムって、新規構築より、もともと使っていたシステムのリプレースが圧倒的に多いんですね。そうすると、前に使っていた設計、設定っていうのが、正しいものとして伝説化されてしまっていることがある。安定稼働しているからっていう理由で、「基本、いじらないほうがいいんじゃないの？」って、設定をそのまま引き継ぐっていうこともあります。それで安心していただけるならいいなと思う一方で、ベストな値があるということも事実なので、そこをきちっと残せているかどうかなんですよね。構築設計の根拠として「こうしました」っていうのが残せているかどうか。あと設計と運用が連動できているかどうかは非常に大事だと思います。
