ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift

最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。

この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。

私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。

・MySQL (RDBMS)
　私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します。Facebookでの使い方に興味のある方は、Percona Live等で私をつかまえてくださればと思います。

・Redis (NoSQL)
　従来型RDBMSで扱いづらいデータ構造であるSortedSetsやListが使えるのが魅力のデータベースです。このためだけにソーシャルゲームのリアルタイム・ランキングや、動画の最新100件とかいった用途に採用しているケースもあります。正となるデータをRDBMSに、キャッシュ的に使うデータ(壊れてもRDBMSから復元可能なデータ)をRedisで、というパターンが多いです。耐障害性に難がありますが、キャッシュとして使う限りは許容範囲内だと思います。

・MongoDB (NoSQL)
　データベース設計ができない/できなかった/する時間が取れない、といった人たちや、Shardingのためのロジックを書くのがめんどくさい、といった人たちを中心に好まれるデータベースです。Facebookでも、子会社の中にMongoDBを使っているところがあります。
　MongoDBを使うか、RDBMSを使うかという議論は、よく「先に楽をして後で苦労するか、先に苦労して後で楽をするか」という表現にたとえられます。「技術的負債」を語る上で良いモデルケースと言えるでしょう。
　稼働までなら、MongoDBの方が、正規化が必須なRDBMSより楽です。その一方で、設計を放棄したツケは、後々になってデータ整合性問題、(重複値の多発による)データ量増加、それによるコスト増といった様々な負債となって現れます。裏の実装はMyISAMと大して変わらないので、データ量がメモリに乗らないくらいの規模になってくると、InnoDBよりも急激なペースで参照・更新性能とも悪化します。典型的な「技術的負債」のパターンと言えるのではないでしょうか。コスト増のことを「技術的負債」と言うのか? という意見もあると思いますが、そのコストの代償として間接的に給与が削減されたり、良いエンジニアを取りづらかったりといった不利益を受ける可能性がありますし、そのコストを減らすためには後々技術的な取り組みが必要になることから、「技術的負債」と言って良いのではないかと思います。ここではこれらの技術的・時間的・金銭的な不利益をまとめて「技術的負債」と呼ぶことにします。

　私が考えるMongoDBの魅力は、多くの場合に、こうした技術的負債を返済しなくて済むということです。負債が顕在化するのは、そのサービスが大きく成長した場合のみです。一般的なサービスの成功確率の低さを考えると、たいていのケースでは負債は返さなくて済みます。これは非常に魅力的なポイントです。競争に勝つためには、早期にサービスを出すことはとても大切で、様々な課題を先送りできるMongoDBがスタートアップを中心に好まれるのはある意味当然とも言えます。そもそも妥当な設計には正規化を中心としたデータベース基礎理論の理解が必要で、それに詳しい人をスタートアップで確保することは多くの場合難しいという事情も無視できません。サービスがうまくいったら、それなりにお金もあるはずなので、データベース設計に強い人を雇用することも難しくなくなってくるでしょう。

　ちなみに、元MySQL社の営業チームのメンバーの中にはMongoDB社に転職した人も何人かいます。上述のように導入時の優位性があるので、MongoDBの営業は「RDBMSよりも速くサービスを作り稼働させることができる」「シャーディングやフェイルオーバーなどの作り込みがいらないので実装コストが低い」などといった売り込みができます。営業は売ったもの勝ちなので、後々技術的負債がどうなるかを考えてくれたりはしません。それどころか、知り合いの賢いMongoDBの営業は、負債の顕在化によって後でサーバ台数がたくさん必要になったり、自動シャーディングやフェイルオーバーが期待通りに動かないことで、お客さんが困ってサポートをたくさん買ってくれるということまで見据えていたりします。怖いですね。
　なお、営業トークの1つである「RDBMSはスキーマ変更が大変」というのは、今の時代それほど重要では無いということを補足しておきます。MySQL5.6(InnoDB)ではオンラインDDLができますし、それ以前のバージョンでも無停止での変更手段はいくらでもあります。どちらかというと自動シャーディングや自動フェイルオーバーの方がセールストークとしては強力でしょう。

　一方でMongoDBを使う側としては、万一サービスがヒットした場合に必ず顕在化するであろう技術的負債について、どう取り組むかは考えておいた方が良いでしょう。現実解としては実績のある他RDBMSへの移行ですが、止めたときにユーザに直接影響が出る用途で使うことが多いでしょうから、移行するのはなかなか大変です。数少ない大規模リニューアル時やメンテナンス時などのタイミングで移すことになるでしょう。
　北米では、「規模が大きくなりすぎたMongoDBベースのWebサイトを、他のRDBMSに移行する」という案件も実際に存在するのですが、MongoDBを最初に導入した人はその時点では退職していたりします。MongoDB社、導入を進めた人、移植先のRDBMSベンダー、移植を進める人たち全員に仕事があるという、経済(GDP)に優しいデータベースとも言えるでしょうか?
　RDBMSとMongoDBのどちらが良いかについて一言でまとめるなら、「サービスが失敗したらMongoDBの勝ち、成功したらRDBMSの勝ち」というのが私の考えです。


・Redshift (ビッグデータ)
　PostgreSQLベースのDWH運用サービスで、AWS上で使うことができます。列指向、圧縮、複数ノード並列処理などひととおりの重要機構を備えています。Facebookでも、子会社の中にRedshiftを使っているところがあります。
　Redshiftは、特にコストパフォーマンスの観点で非常に優れています。2TBあたり年間数十万円で使えるという低価格は、1つのイノベーションと言えると思います。登場し始めた頃は、1週間で100社のペースで顧客が増えていたそうで、これを使うためだけにAWSに移行したという話も聞いたことがあります。機能の追加も良いペースで行われています。HDDベースとSSDベースがあり、価格と性能のトレードオフを踏まえた上で選べば良いでしょう。

　ビッグデータを扱う環境では、技術的負債という観点において、上に書いたMongoDBとは状況が異なります。すでにたくさんデータがあるということは、サービスとしてはそこそこ当たっている状況のはずです(そもそもデータが数10GBとかしか無ければ、RDBMSで十分です)。この先サービスが収束して終了する可能性はほぼ無いと考えられます。多くのスタートアップがMongoDBを使う背景にある「サービスが早期終了すれば負債は残らない」という予測は、DWHを必要とするほどの環境になると期待できません。負債は必ず顕在化します。必ず顕在化するのであれば、そうならないように事前に手を打っておくことはとても重要です。
　正規化などを含めた様々なことを先送りして、Redshiftのかわりに他の手段を採用するとした場合、その代償について慎重に吟味する必要があります。特に容量単価をはじめとしたコスト面で割高な場合は、データ量が増えれば増えるほどコスト差が広がるのでより深刻です。サービスが存続する限り、拡大するコスト差を負担し続けなければならず、それを改善するためには、データの削除や保持期間の縮小、後からRedshiftに移行する、といった手間をかけなければいけないからです。これも「技術的負債」の典型的なケースと言えます。
　このような点から、私はビッグデータに関しては、後で苦労するくらいなら先に苦労した方が良いという、技術的負債を先送りしないアプローチを取りたいと考えます。現時点での私の大まかな感覚では、これから3年間使うとして、そのトータルコストが4TB(圧縮後)あたり600万円～900万円(3年の累計)、10TBあたり1000万円～1500万円のレンジを超えてくるようなら、すでに技術的負債と言える(=より低コストな手段を模索すべき)と思います。このレンジは時間の経過とともにもっと下がるのは確実です。
　AWSでビッグデータを扱うのであれば「Redshiftを使いこなせれば勝ち、そうでなければ負け」というのが私の考えです。幸いDWH環境の場合、メインのWebサービスに比べて可用性や安定性に対する要求が低く(利用者が社員など一部に限定されるので)、止めて移行することは現実的に可能です。だからこそ過剰投資を防ぐ余地があります。すでに高コストな選択肢を選んでしまったとしても、手遅れではありません。稼働後もいかに(Redshiftなどで)トータルコストを下げる(技術的負債を減らす)かを模索していくと良いのではないかと思います。こうした低コスト化の推進の効果を、エンジニアたちの所得アップに還元してくれる会社がたくさん出てくると良いなと思います。

　Redshiftを見ていると、商用RDBMSの世界を徐々にMySQLが侵食していった頃のことを思い出します。当然ながら商用DWHベンダーにとって、低価格なRedshiftの登場は面白く無いわけです。「MySQLはXXがダメだ、だからYY(商用RDBMSの名前)を使いましょう」とアピールしていくことが、(より高い)商用RDBMSベンダーや、そのパートナー企業の人たちの仕事でした。ユーザにとってベストなのかどうかは関係ありません。ベンダーにとってベストなことをするのがベンダーの論理です。MySQLは最もコスト競争力が高いRDBMSだったため、歴史的にずっとこの攻撃を受ける側でした。同じように、商用DWHベンダーは、例えRedshiftで実現可能なことであっても、さも実現できないかのようにアピールし、自社の(より高い)DWH製品を勧めていくという戦略を取ります。ユーザーのためになっていないですが、それが商用DWHベンダーの人たちの仕事なのです。読者の皆さんには、こうしたネガティブマーケティングに惑わされないようにしてほしいと思います。

インフラエンジニアのキャリアとクラウドについて

もう注目されるようになって久しいクラウドについて、思うところを書いておきます。

LinuxなりMySQLなりといったインフラ技術のスペシャリストの人が、GoogleなりFacebookなりといったサービス事業者で働くことは珍しくありません。これはそうしたサービス事業者にとって、インフラ技術のスペシャリストがある程度必要だということでもあります。ではこれからLinuxなりMySQLなりのスペシャリストになりたいという人(新卒/中途問わず)はどういう会社を目指すのが良いのでしょうか。私は本家ベンダー(RedHatなりOracleなり)や大手サービス事業者(FacebookなりDeNAなり)が良いと思っていますが、一点「クラウド上で主力サービスを展開している事業者」はやめた方が良いと考えています。

なぜなら、インフラ技術を語る上で欠かせないハードウェアとネットワークが、クラウド上ではブラックボックスになるからです。これらはパフォーマンスチューニングにしてもトラブルシューティングにしても極めて重要なスキル要素で、それらをブラックボックスにしたままではインフラ技術者としての成長は早々と止まってしまいます。ブラックボックスのままで良いと考えているなら、そもそもインフラ技術者を目指さない方が良いと思います。

またHerokuやAmazon RDSのような便利なサービスも増えているのですが、こうした「SaaS型のサービスを活用しています」と嬉々として宣伝している会社も、インフラ技術のスペシャリストを目指す上ではふさわしい所ではありません。Webサーバなり、MySQLなり、Hadoopなりといった中核のソフトウェアを自分たちでは運用しきれませんでしたと認めているに等しいからです。上層部がそうした技術のスペシャリストに大きな価値を見出していないということでもあります。

もちろん、サーバ運用費や人材育成などのコスト面から、こうした選択をした方がビジネス的に良いケースが少なくないことは十分承知しています。それでも、インフラ技術のスペシャリストを目指すのであれば、自分たちでなんとか要素技術を活用しようと努力している所を選んでほしいと思います。もちろん、OracleやClouderaなりといったベンダーからコンサルを受けるなりといった形でも良いです。エンジニアとしての成長の余地が大きいと思うし、会社から期待される度合いも高いと思います。

これからクラウドがさらに台頭していくのは間違い無いですが、クラウドのスペシャリストとは現在は事実上AWSスペシャリストであるわけです。それを目指すならAmazonに行くのが一番手っ取り早いです。Amazonで働いたことはありませんが、出しているサービス(RDSなりRedshiftなり)を見る限りではインフラエンジニアにとって非常に魅力的な環境だと思います。そして自前でサービスを運用している事業者でハード/ソフト面の両方でインフラ技術を磨いていれば、おのずとそのチャンスは訪れると思います。

米国への引越とFacebook入社のご報告

件名の通り、私は米Facebookに最近入社したことをここでご報告します。

相変わらずMySQL関係の仕事をすることになります。
チームメンバーはアジアには誰もおらず大半が米国本社(Menlo Park)にいるため、自分も引っ越すこととなりました。
すでに生活の拠点を会社から10km未満というそう遠くないところに移しています。

当然ながら入社前に話をオープンにするわけにもいかないので、DeNAの中の方たちや、ごく親しい人にしかご挨拶ができずにすみませんでした。

このBlogの読者であればご存知のように、私はキャリアの途中からほぼMySQL一本で仕事をしてきています。

実はDeNAは、世界でも指折りのMySQLのヘビーユーザとして認知されています。
去年の米MySQL Conferenceでは会社としてAwardを受けました。それも純粋に技術的な貢献が評価された上での受賞であり、「日本でのコミュニティ活動に貢献した」のような海外のユーザにとって技術的な意味のないものではありませんでした。MySQLヘビーユーザ企業としては国内では文句なくNo.1で、海外でも2-5番目くらいの位置にいると言えるでしょう。

では世界で最もMySQLを使い倒しているユーザ企業と言えば、それはFacebookであることに疑いの余地はありません。
というわけで引き続きMySQL関係のお仕事をやっていきます。

DeNAでは1年半しか仕事をしなかったのですが、実力のある同僚に恵まれたこともあり、マスターの無停止切り替えや自動フェイルオーバーによる可用性の向上、効率化/高速化によるコスト大幅改善など、良い成果を出すことができました。
去年の後半には社内で社長賞を頂いたのですが、言うまでもなくそれは周りの方のおかげです。
一度問題を解決すると、類似の問題をことごとく自力で解決してくれる有能な若手技術者に恵まれたことや、マネジメント層が色々と気を使ってくれたりしたことで、
自分が現場にいながらにして中長期的な施策に多くの時間を割くことができました。
インフラチームや、ソーシャルゲームチームの同僚たちにとても感謝しています。ほかの会社ではこの短期間で同等の成果を出すことは難しかったと思います。
ですから、今でもエンジニアに対してDeNAという会社を自信を持って勧めることができます。

では、なぜ移るという決断に至ったのかというと、それは去年後半にお誘いを受けたというのが直接のきっかけではあるのですが、以下のような様々なことを考えて総合的に決めました。

・データベース技術の未来について
　・データベース技術にはどのような分類があり、
　それぞれの領域は今後どのように進化していき、
　どのような人材が求められるようになるのか、
　ということに対する自分の考え

・エンジニアのキャリアについて
　・インフラエンジニアのキャリア形成について
　・一点集中型と全方位型の違いについて
　・枯れた技術と新しい技術の違いについて
　・ベンダーとサービス企業の違いについて
　・海外に住んで働くということについて
　・日本という国についてどう思っているか
　・家族/結婚/出産/住宅ローンなどについて
　・ソーシャルゲームやライバル企業について

2月末に、DeNAの多くのエンジニアの方に対して、この「データベース技術の未来と エンジニアのキャリアを考える」というテーマで90分間にもわたって自分の考えを発表させて頂くという機会を頂きました。この内容は社外秘の情報を含むのでここでお見せすることはできませんが、参加してくださった方々の反応を見てもかなりの手応えがあったので、自分としても後悔の無いようにやっていきたいと思います。

今後ともどうぞよろしくお願い致します。

新著「Webエンジニアのための データベース技術[実践]入門」

データベース技術に関する新著を執筆しました。「Webエンジニアのための データベース技術[実践]入門」という本です。



第1章：データベースがないと何が困るのか
第2章：インデックスで高速アクセスを実現する
第3章：テーブル設計とリレーション
第4章：SQL文の特徴とその使いこなし方
第5章：可用性とデータの複製
第6章：トランザクションと整合性・耐障害性
第7章：ストレージ技術の変遷とデータベースへの影響
第8章：データベース運用技術の勘どころ
第9章：MySQLに学ぶデータベース管理
第10章：MySQLのソースコードを追ってみよう
第11章：データベース技術の現在と未来
第12章：ビッグデータ時代のDB設計

---「はじめに」より
　私たちが日々活用しているオンラインサービスでは、ほぼ例外なくデータベースが背後で重要な役割を果たしています。ブログサービスのような無料のものだけでなく、ショッピングサイトのようにお金が動くもの、オンラインバンキングのように高額のお金が動くクリティカルなものに至るまで、あらゆる環境でデータベースは使われています。これらのサービスは例外なくデータを保存しておく必要があり、そのデータの保存場所がデータベースです。
　私たちは、背後のデータベースがどうなっているかなどと意識することなく、こうしたサービスを使うことができます。ただ、そのサービスの「質」を意識させられる場面は少なからずあります。頻繁にアクセス不能に陥ったり、応答時間が遅かったりするサービスは少なくありません。こうした質の問題は、背後にあるシステムの品質に大きく依存します。データベースもその中で非常に重要な役割を果たしています。
　データベース自体の歴史は長く、インデックスやデータモデリング、トランザクションといった基幹の技術は大きくは変わっていません。それにも関わらずデータベースに起因する問題がよく発生するのは、データベースに対する理解が十分ではないからというのが大きな要因でしょう。本質を理解すれば、流行に振り回されることなく適切な設計ができるようになるはずです。
　本書は、データベース技術のトレンドを整理して体系的に解説することで、こうした本質面での理解ができるようにすることを目指した書籍です。元々は技術評論社のSoftware Design誌に連載したものをベースにしています。Software Designや姉妹誌のWeb+DB Pressでは筆者が専門としているMySQL関連の特集記事の執筆などを行なったことがあり、これらのトピックも取り入れています。本質面での話と、MySQLの具体的な話を織り交ぜることで、より理解を深められるような構成を心がけたつもりです。
---

　小手先のツールが使えようが何だろうが、基本を知らん奴はトラブルの現場では何もできやしない、ということで、データベース技術の歴史を振り返り基礎をおさえたい方におすすめです。

MHA for MySQLとオープンソースとDeNAの話

　実に久しぶりの投稿ですが、最近リクルートのセミナーで、私が少し前に公開した「Master High Availability Manager and tools for MySQL (MHA)」と、オープンソース界隈の技術者として、DeNAでどのような活躍の可能性があるかといった話をしてきました。

MHA for MySQLとDeNAのオープンソースの話

View more presentations from Yoshinori Matsunobu

　ust配信とかはしていなかったので残念ながらデモ動画は残ってませんが。。

　何点か今の時点での私の考えをまとめると、以下のような感じです。

・どのように作るかよりも何を作るかの方が大事だと思っている
・そのプロダクトの技術力が最も高いのはベンダーだが、何を作るかという発想はサービス会社での経験から生まれることも多いと思っている
・DBスペシャリストのような特殊技能を生かした仕事をサービス事業者で行なうには、大規模サービス事業者でないと現実的には困難
・今の為替レートは海外で働くには不利すぎる。今のご時世、海外でないとできないことはそれほど多くない
・とはいえ、スペシャリストとしてキャリアを築くのであれば、海外のカンファレンスなりである程度発信し続けることは必要。そうした活動に対する理解のある会社で働くことは重要(こうした理解が本当にある日本企業はとても限られているので注意)。

　DeNAに入ってから1年強が経ったのですが、これまではおおむね自分の想定通りに働けている感じで満足しています。

Leaving Oracle, Joining DeNA

　9月1日付けでオラクルを退職し、9月2日付けでディー・エヌ・エーに転職しました。新会社への入社の報告よりも(だいぶ)前に退職の報告をする方が多いようですが、私が外向けにオラクル退職の報告をするのはこれが初めてです。退職と転職の報告と同時に行なうのは、多くの方がナーバスになっているオラクルとMySQLの行く末について、できるだけ悪い印象を与えたくないと考えたためです。ディー・エヌ・エーは世界でも指折りのMySQLの超ヘビーユーザとして知られています。オープンソースの世界では、ベンダーからヘビーユーザの事業会社に転職し、その専門性を生かした仕事を続けることは珍しくありません(オープンソースのメリットの1つです)。というわけで、引き続きMySQLの仕事を続けます。MySQLコミュニティの方はどうか安心してくださればと思います。今後ともどうぞよろしくお願い致します。

　私は2006年9月にMySQLに入社して以来、2度の買収(サン、オラクル)を経て、のべ4年間を「MySQL本家のMySQLコンサルタント」として過ごしてきました。サービスに対して対価を受け取るコンサルタントとして勤務するのも社会人として初めてのことだったのですが、それ以外にも以下のような得難い経験をさせて頂いて、自分にとって忘れられない4年間となりました。

・米国やインドなど海外の顧客に対する難度の高いコンサルティング業務の遂行
・MySQLの開発者会議への参加や、コードのコントリビュートを通じてのOSS活動
・多いときは月数回の海外出張
・上司がアメリカ人。人事考課や交渉事なども米国流で当然すべて英語
・同僚や顧客の多くが外国人で、時差を調節しながらの在宅勤務をベースとした仕事
・メール、会議、カンファレンス等はすべて英語。質疑応答なども当然英語

　英語圏の企業で働くということは、言葉が変わるだけでなく文化も当然のことながら大きく異なるわけで、この点については「会議で言葉を英語にしただけの日本企業」では決して得られない経験ができたと思います。特に、彼らの本当の意味でバランスの取れた「ワーク・ライフ・バランス」には驚きました。年間25日の有給を取ったり、1ヶ月の長期休暇を取るようなワークスタイルは、ただ時間をかけて働くことが全てでは無いと改めて感じるものでした。1ヶ月ホテル暮らしでその月の経費精算が100万円を超えたことや、オフィスへの定期代の支給をしてもらうためにSkypeで上司と(米国では定期代支給の文化が無い)激論を交わしたことも今となっては良い思い出です。また英語漬けの環境で、私自身もずいぶんと国際化した感じがしました。趣味の面では、マンU vs チェルシーを現地観戦したり、米国でマリナーズ戦を観たりと普段できないことができて良かったと思います。

　ソニーで5年半働いた後に、2006年9月にMySQLに入社した時は、会社が存続する限り働きたい、できれば5年は持って欲しいと思っていました。まさか1年半弱で(サンに買われたことで)会社が無くなってしまうとは想像もしていませんでした。また、サン自体もソニー時代からよく知っていた会社で、多少なりとも愛着があったのですが、最終的にBEAとかマカフィーすらも下回る企業価値となって消滅したことは残念でなりません(Javaの本家なのにWebLogicより価値無いのかよ!)。ですが、オラクルは安い買い物をしたと確信しています。MySQL、サン、オラクルと、のべ4年間をMySQL本家で働けたことに後悔は全くありません。特に2007-2008年は良い同僚にも恵まれ、幸せでした。

　2度の買収というのは精神的にも事務手続き面(経費精算とか勤務管理とかの諸制度も変わる)でもタフなイベントだったのですが、最後にオラクルで働く中で「MySQLデータベースの行く末はまだまだ安泰」ということを強く感じました。性能面、拡張性、ユーザーベース、品質担保、使い勝手などどれを取ってもMySQLはきわめて優れており、だからこそ世界中で支持されてきたのだと思います。多くの方はすでに忘れているようですが、MySQLの中核のInnoDB(の開発元のInnobase)は、2005年にオラクルに買収されました。当時は誰もがMySQLは終わった、InnoDBはもう進化しない、と考えましたが、その後の進化ぶりは見ての通りです。InnoDB作者のHeikkiをはじめ、MySQL/InnoDB開発者の大半は今もオラクルに在籍しています。簡単にMySQLをオープンソースRDBMS2番手以下の地位に甘んじさせるとは考えられません。また製品評価の指標から見落とされることが多いのですが「品質」は極めて重要なポイントで、この品質は最終的には多くのユーザから使われることによってのみ担保されます。現在ユーザーベースでぶっちぎりの一番手にいるMySQLよりも品質の良いオープンソースの代替製品が果たして出てくるのかどうか。MySQLの行く末に不安を持つ方も多いと思いますが、片手間ではなく本気でMySQLを使っている人こそ、この点について共感してもらえるのではないでしょうか。


　新しい職場のディー・エヌ・エーのことについても話をしたいと思います。ディー・エヌ・エーと私の関わりは今に始まったことではなく、実は3年以上前からお誘いの話を頂いていました。私自身がMySQL本家を辞めることを考え始めたのはごく最近のことだったのですが、ちょうどその時期にディー・エヌ・エーがMySQLのスペシャリストを探していたのでラッキーでした。同じ時期に米国と欧州のMySQL系企業からもお誘いの話を頂いたのですが、海外の企業からそういった話が自分のところに来るというのはMySQLに行く前はありえなかった話で、自分自身も成長した気がします。日本で面白い職を見つけられたことは良かったし、私に対して価値を見出してくれたディー・エヌ・エーの方にはとても感謝しています。チームメンバーのこれまでの成果(オープンソース製品やDBマガジン等の記事など)を見るに、技術レベルが相当に高いという印象を持っています。その環境はプレッシャーにもなりますが、真のグローバル企業であったMySQL社の中で積んできた経験と知識・感性を真正面からぶつけていくことで、早期に貢献していければいいなと思っています。どうぞよろしくお願い致します。

デブサミ2010でLinux/DBに関する話をします

デブサミ2010で「高性能・安定運用のためのLinux-DBシステム構築/運用技術」というタイトルで講師をすることになりました。2010年2月18日の13:10から14:00のセッションです。
DB サーバには、RDBMSはもちろんのこと、OSやハードウェアも当然必要ですし、運用管理ツールやクラスタリングソフトウェアなどの支援ツール併用することも多いです。現実の運用では、支援ツールを使うことによって引き起こされるトラブルもあります。DBサーバを取り巻く全体像を把握した上で適切な対処を取れることが大切です。本セッションではこうした話をします。またRDBMSを安定稼働させ、かつ性能を発揮させるにあたって、ハードウェア、スワップ、ファイルシステム、I/Oスケジューラ、Linuxカーネルなど、どういった要素や現実問題としてトラブルになりやすく、どうすれば効果があるか、といった実戦的な話もします。
書籍「Linux-DBシステム構築/運用入門」とタイトルが大きくかぶっていますが、この本をすでに読まれている方にも、読んだことの無い方にとっても役立つ話をしたいと考えています。ご期待下さい。