セッションについて
DB Online Day 2018 Summer (DB Online Day 2018 Summer)
スペシャルセッション データで見る、経験で語る、日本のデータベーススペシャリストのリアリティ
の聴講メモです。
本セッションはパネルディスカッション形式で行われました。
モデレーター：DB Onlineチーフキュレーター 谷川 耕一 さん
パネリスト：株式会社アシスト 関 俊洋 さん
パネリスト：日本オラクル株式会社 小田 圭二 さん
自分のメモをベースにまとめています。発言の聞き間違い、解釈違いの可能性があることをご了承ください。
テーマ1 3種のデータベースエンジニア
Oracleでは社内外（主に社外）のDBAのスキル調査を行っている。このデータの分析結果をお話ししたい。
DBAを3つに分類し、各役割を整理する。
| 開発側DBA | SQLチューニング、インデックス設計、バグ調査。 |
| 運用側DBA | キャパシティ管理、トラブル対応、バックアップリカバリ、SQLチューニング。 |
| 全体最適DBA | 一部の会社で任命している。品質管理、障害の横展開、標準ガイド作成、レビュー、難易度の高いトラブル対応。 |
DBAにはインフラスキルも必要。これがないとスキルが伸びない。
経験とスキルは比例している。DBAとして一人前といえるレベルには5～10年ぐらいの経験が必要になる。3年目では若干足りないぐらい。
SQLチューニングは運用フェーズでのタスクと思われがちだが、本来は開発段階から意識すべき。少ないデータ量で性能テストして本番で火を噴くのが最悪パターン。
開発側にいるとDBAとしての幅広い経験ができない。運用側のスキルが伸び悩む。運用の経験が大事。
運用は比較的速くスキルが伸びる傾向にある。
品質管理チームは経験が少なくともスキルの高い傾向にある。チームメンバーの年齢層が高いので、比例してドキュメンテーション能力が高い。
情シスは経験年数を積んでも一人前レベルに達していない。
でも、SIerも同じ傾向。特に大手は手を動かせていない印象がある。
アーキテクトやコンサルはスキルが高い傾向にある。
ドキュメンテーションやコミュニケーションスキルはかなり重用。時には技術スキルより重用となる場面がある。
データからもドキュメンテーション・コミュニケーション・インフラのスキルを持つエンジニアは年収が高い傾向にある。
データベースはインフラを知っていると応用が利く。SQLチューニングだけではその分野に特化してしまう。チューニングを専門にしている会社ではスポットでプロジェクトに参画し、仕事を終えると抜けることが多い。
劣化した性能をチューニングして回復させたとしても、元を越えることはできない。その壁を越えるためにインフラスキルが必要となる。
テーマ2 DBエンジニアの専門性スキルをどう捉えれば良いのか
チューニングで大切なのは目標を設定すること。また、SQLチューニング以外の手段も含め提案できること。
チューニングは今後もなくならない領域。自動化できる領域は増えるが、匠の領域がある。匠の領域では中身を理解している必要がある。
インスタンスチューニングで求められることの一つがメモリー関連パラメーターのチューニング。これには自動化・ユーザー数・セッション数・ロック等が関連してくる。これらの問題を解決することがインフラエンジニアとして求められる。
開発側が提示するパラメーター設定資料にはしばしばパラメーターの設定理由が書いていない。設定の見直しにあたっては根拠をもって見直す事が大切。
Exadataにはベストプラクティスがあるが、既存からのリプレースだと、過去のパラメーターを変えることに難色を示されてしまうことがある。
アシストの実感として、テーブル設計をできるエンジニアは減ってきている。データモデルを考えることのできるメンバーがベテラン層に寄ってきている。
データベースエンジニアと呼ばれる人はシステムが使われる業務の現場から離れていることが多い。
モデラーと呼ばれる人は変わった人が良い。何人か集まればみんな違った持論を展開する。
バックアップを設定したことはあっても、実際にリカバリーしたことのない方が多い。事前に検証環境でもいいからやっておくべき。そうでないと、現場でヒリヒリした思いをすることになる。
データベースの内部構造を知らないと、障害の発生している現場での疑問に答えることができない。これは場数を踏んで経験を積むしかない。
トラブル時は例外的な壊れ方をすることが多い。これはツールで救えないこともしばしばある。
英語は使わないと覚えない。まずはドキュメントを読む。下手でも良いからしゃべる。IT人材不足の話が出たが、人が減れば外国のエンジニアとの協業が必要になる。そこで英語が必要となるはず。
Oracleに関しては日本語ドキュメントがある程度そろっているが、クラウド系だと英語ドキュメントを参照する必要がある。
英語ドキュメントはGoogle翻訳でも良いから読んでみる。翻訳を待っていると時間がかかりすぎる。
Oracle内部では未だに現地の言葉に翻訳しているのは日本ぐらいと言われている。
テーマ3 DBエンジニアのスキルアップにどうアプローチする？
キャリアのスタートがインフラか開発かでデータベースへの見方が決定的に違う。開発から始めたエンジニアはデータベースを単なるデータの入れ物とみていることが多い。開発エンジニアもインフラ視点で見ると気づきがあるはず。
開発側も経験することのメリットにアルゴリズムの理解が早くなることが挙げられる。
運用側から入ったエンジニアはインフラ全般、特にトラブル対応のスキルが伸びやすい。一方、安定稼働してトラブル対応が減った現場ではエンジニアのスキルが伸び悩むこともある。
トラブルが起こった現場に行くと、ステークホルダーの関係性や業務影響のインパクトを肌で感じられる。
クラウド時代にネットワークのスキルは大切だが、全てのスキルを満点にする必要はない。得意分野を持ち、苦手分野は任せるかお金で買えば良い。お金で時間を買う。データベースエンジニアとしてはデータベースを中心に、ネットワーク、ストレージのような他の2,3スキルを掛け算する。
どれだけAIが進化しても、お客様とビジネスを一緒に考える仕事はなくならない。
データ活用はそんなに簡単じゃない。データはあっても定義がなかったりする。
アシストではデータベースの活用はほかの部署と分けている。それぐらい難しいし、専門的スキルが必要になる。
ユーザーのリクエストに応えて正しいデータを提供できているのは半分以下という報告もある。
分析の時間は5%以下。それ以外の大部分の時間はデータクレンジングに使われている。
テーマ4 クラウドになるとDBエンジニアはどうかわるのか
Oracleのクラウドはバックアップの自動化ができる。細かい設定はできないが、難しいバックアップ設計を任せることができる。
Oracleはオートノマスで自動的にチューニングする。そのため、デフォルトではインデックス作成すらできない（エラーになる）。
OracleでDBエンジニアのタスクを整理したところ、120ぐらいあった。だから、何を自動化に任せ、何を尖ってスキルとして身につけるかを考えていく必要がある。Oracleとしては自動化でDBエンジニアのタスクを半分程度に減らせると考えている。ただし、現場によって状況は変わる事に注意。
ベンダーやSIerとしてはオートノマスで食い扶持が減ると感じるかもしれないが、工数が減ることで期日を守りやすくなることをメリットとして捉えることもできるはず。
例えばバックアップの自動化にはOracleのベストプラクティスが適用されている。都度設計しなくて済むことは大きい。
日本のミッションクリティカルなシステムにはIaaSがあっている。リフト＆シフトのやり方。だが、PaaSにしていかないと構築や運用タスクが減らない。IaaSで始め、PaaSに進めていくのが良いのでは。
クラウド化してもチューニングの要素はなくならない。SQLチューニングだけでなく、スケールアップやキャッシュなどのクラウドならではのテクニックが使える。
クラウドによってパケットキャプチャでの解析が改めて重要になってくる場面も出てきている。
アシストではExadataの価格を自社サイトで公開しており、このページへのアクセス数が多い。価格に興味を持つ方が多いということ。クラウドサービスでも価格情報がオープンになっている。ユーザー自らコストを踏まえて判断・提案するようになってきたし、エンジニア側もコストについて理解していないといけない。
Ask The Speaker
セッション後、登壇者のお二人に質問してみました。
Q.
セッション中に技術分野を深堀するという話が出たが、どこまで深堀して進むべきか？どこであきらめるか？
A.
人によって壁に突き当たるところがある。そこまで進めて、一旦他の事へ進め、また必要になったり壁を乗り越えられるようになったら進む。（小田さん）
マネージャーとしては会社の方向性と個人の方向性にギャップがあるとき、個人のやりたいことを伸ばしてやり、マネージャーがそのギャップを埋める。マネージャーは忙しくなるが…。（関さん）
所感
今回のセッションを通し、知識と経験は両輪であり、どちらも必要なことであると改めて感じました。
例えば、パフォーマンスチューニングを解説した資料は数多くありますが、現場でそれを適用しても思ったような効果を得ることは難しいと感じています。ですが、そうした知識が無駄なわけではありません。なぜそれがうまくいかないかを考え、別の方法を考え付くためにさらに幅広い知識が必要となります。そして、そこでの経験が次回のチューニング作業を効率化してくれます。
自動化が進めば半端な知識や経験では太刀打ちできなくなるでしょう。そんな状況下でもエンジニアとしての価値を出すためには日々の研鑽あるのみ、ということではないでしょうか。
