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システム構築/運用入門」とタイトルが大きくかぶっていますが、この本をすでに読まれている方にも、読んだことの無い方にとっても役立つ話をしたいと考えています。ご期待下さい。

MyISAMとInnoDBのどちらを使うべきか

Twitterで話題になってたので簡単にまとめました。

●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない
・全文検索 (TritonnやSphinx)
・GIS

●InnoDBの利点(MyISAMの欠点)
▲障害対応系
・クラッシュしても再起動するだけでリカバリができる
・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある)
・オンラインバックアップができる
・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い

▲性能系
・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSELECTと更新系SQL文が競合しない。
・主キー検索が高速 (クラスタ索引のため)
・ダイレクトI/O(innodb_flush_method=O_DIRECT)を使えるためキャッシュ効率が高い
・インデックスの追加/削除をするにあたってテーブルを再編成する必要がなく、そのインデックスだけを再構築するので効率が良い(InnoDB Plugin)
・Insert Bufferという仕組みにより、セカンダリインデックスへのINSERT処理の効率がMyISAMよりも良い

▲従来は欠点だったが、InnoDB Pluginによって改善されたもの
・グループコミットが無効化されるため同時更新性能が著しく低下していた
・I/Oスレッドが事実上読み書き1本ずつしか無かったため並列性が低く、RAIDやSSDを有効活用できなかった
・CPUスケーラビリティが悪く、4CPUコアくらいまでしかスケールしなかった
・同じ量のデータを投入してもテーブルサイズがMyISAMよりも倍以上大きくなることがある(InnoDB Pluginの圧縮機能を使うことで緩和する手がある)

▲ほか
・InnoDBでは外部キーが使える


●MyISAMの利点
・WHERE条件無しのSELECT COUNT(*)が一瞬で返る
(InnoDBの場合はテーブルをなめる必要がある)
・メモリにおさまらないほど巨大なテーブルのフルテーブルスキャン系の処理効率が良い
(InnoDBではこうしたバッチ処理でバッファプールの中身が追い出されてしまうし、バッファプールの管理オーバーヘッドもあるが、MyISAMは専用のバッファプールを持たないので効率が良い)
・OSコピーによってテーブルの移動が極めて簡単にできる
・MERGEテーブルを使うことができる (InnoDBでも5.1のレンジパーティショニングを使えば十分なことは多い)
・リードオンリーのテーブルであれば圧縮できる
・ALTER TABLE ENABLE/DISABLE KEYSを使える。例えばインデックスなしの状態で高速にロードして、後からインデックスを有効化とかができる (InnoDB Pluginではインデックス単位の再構築ができるのでかなり緩和できる)
・InnoDBはテーブルのオープン処理がシリアライズされるため、大量の数のテーブルを初回オープンするような処理がきつい

▲ソリューションによって緩和できるもの
・クラッシュ時に壊れる問題やリカバリ(REPAIR TABLE)の遅さは、生きているスレーブを使って復旧すれば解決できる
・テーブルが巨大になることで引き起こされる性能問題は、小さなテーブルに分割することで解決できる


　自分は、特別な事情が無い限り、5.1最新版に含まれるInnoDB Pluginを勧めています(*注)。ログ蓄積系のテーブルではMyISAMが良いと考えている方が結構多いのですが、MyISAMでは複数のクライアントから同じテーブルに対してINSERTをすれば競合してしまいますし、InnoDBのInsert BufferのようなI/O最適化の仕組みが無い(詳しくは「Linux-DBシステム構築/運用入門」の9章あたりを参考にしてください)ので、InnoDBに比べても処理効率が悪いです。MyISAMを活用する場合は、上に挙げたようなテクニックを使って問題を緩和するのが効果的です。
　ちなみに、マスターをInnoDBにして、スレーブをMyISAMにするのは以前Postしたように特別な注意が必要です。

(*注追加) InnoDB Pluginの現時点での位置づけはベータです。ただし、Dynamic/Compressedという特別なテーブルフォーマットを使わない限り、既存のInnoDBテーブルと互換性があるので、InnoDB Pluginを使いつつ、不安定な現象に遭遇したらパラメータを変えて通常のInnoDBに戻すことが可能です。追加インストールやインストールし直し等が必要ないという手軽さが魅力です。

Okyuu.comからインタビューを受けました

　先日カカクコムさんが運営しているサイト「Okyuu.com」からインタビューを受け、その記事が公開されました。
　私は幼少の頃から技術者魂全開、というキャラとは程遠く、気づいたらこの業界でDB技術系の仕事をしていた、という程度なのですが、趣味と仕事が完全に一致したという恵まれた方はむしろ少数派で、多くの方は生活のために(それと多少の興味と一致して)この業界で仕事をしているのだと思います。この業界はコードを書くのが趣味でなければ生きていけない、というプレッシャーをひしひしと感じさせますが、そうでない人にとっても活躍の場はあるのだ、という安心感を持っていただけると幸いです。
　インタビュー記事について、少しだけ補足をしたいと思います。

・お金を払うユーザーを大切にするのは当然ですが、無償で使うユーザーを無視しているわけではありません。そもそも無償で使うユーザーを無視するようではOSSビジネスは成立しません。多くの利用者が試し、時に地雷を踏みそれを修復するサイクルを繰り返すことで、ようやくお金を払っても良いかなという品質に達すると考えています。誰も使っていないプロダクト(地雷を踏むリスクが高い)にお金を払うユーザーは、昨今では非常に少ないのではないでしょうか。

・第3者企業がOSS製品をさんざん利用した挙句、ちょっと機能を追加してクローズドソースにして「自社製品です」と言い張って販売するのは、私は「邪道」のビジネスだと考えています。もちろん程度問題で、ユーティリティライブラリ程度なら全然いいと思いますが、コアの機能がもろにOSSを使っているのなら、それを拡張してクローズドソースにして販売するくらいなら本家にフィードバックしろよ、と思うわけです。

・OSSに貢献する道は、パッチを書くだけではありません。たとえば新バージョンのバグを見つけてバグレポート上で再現手順を報告するというのも立派な貢献です。こうしたバグ報告によって製品の品質は徐々に上がっていきます。その意味では、会社としてはお金を出せないしパッチを書くほどのスキルは無いけどOSSに貢献したい、というような方は、できるだけ新しいバージョンを積極的に使って、バグを見つけて報告するのが良いのではないかと思います。ただし、セキュリティ上の脆弱性に関しては、バグフィックスよりも先にBlog等で発信して一般に認知されたりすると、攻撃の対象になりかねないので気をつけて頂きたいと思います(MySQLのバグレポートでは、脆弱性の問題については、報告を受けた後に一般ユーザーが閲覧できないように権限設定されます)。

スワップサイズをゼロにしてはいけない

　先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。
　まず、本書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、この本をほめてくださっていることに大変感謝しています。まだ本自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。

　最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をしています。64ビット機と数十GBクラスの大容量メモリを搭載するのが現在のトレンドになりました。ディスクI/Oの速度はメモリアクセスに比べて極端に落ちますから(第10章参照)、できるだけ多くのデータをメモリ上に置いて高速化をはかるというのがDBチューニングの定石です。多くの場合、メモリを増設することで参照性能だけでなくINSERTなどの更新性能も上がるというのは第9章などで触れている通りです。またダイレクトI/Oを使ってキャッシュ効率を上げることも効果的です。InnoDBならinnodb_flush_method=O_DIRECTを指定すれば良いです。

　メモリ管理の設定でよく見るのが、スワップサイズをゼロにしているケースです。スワップサイズをゼロにすれば、スワップが発生しませんが、これは問題があります。本章で書いているように、プロセスが実メモリを使い切ってしまった場合に、スワップできないのでOOM Killerによって殺されてしまいます。また、このときにハングアップ状態がしばらく続き、挙句の果てに異常終了してしまうためです。単に再起動したとしても、ダイレクトI/Oであればプロセス空間のキャッシュだけでなく、ファイルシステムキャッシュ上に何も載っていない状態からスタートするため、ディスクI/Oが多発して性能が一気に低下します。もちろんDRBD等によるアクティブ/スタンバイ構成でフェイルオーバーするような場合も、フェイルオーバー先にはキャッシュに何も乗っていないため、同じように性能が落ちます。スワップサイズが小さい場合も、それを使い切れば同様にOOM Killerに殺されてしまいます。このため、「スワップサイズをきちんと(物理メモリの半分くらい)取り、ダイレクトI/Oを使い、プロセスよりもファイルシステムキャッシュが優先的にスワップされるようにvm.swappinessをゼロにする」という方法を紹介したというわけです。もちろん、スワップが発生するというのはディスクI/Oが頻発するという意味なので、それを避けるように実メモリの範囲内におさまるようにチューニングするのが大切です。

　なお、MyISAMテーブルなど、ダイレクトI/Oをサポートしていないストレージエンジンでは、RDBMSのプロセスサイズが小さくなり、ファイルシステムキャッシュのサイズが大きくなる傾向にあります。この場合、プロセスだけでメモリ空間を使い切る(OOM Killerによって殺される)ことはまず無いでしょう。

新書籍「Linux-DBシステム構築/運用入門」

　Linux上で「高速で、落ちない」DBサーバーを構築するための技術解説をした書籍を出版します。タイトルはストレートに「Linux-DBシステム構築/運用入門」です。
　9月17日発売ですが、ジュンク堂など一部の書店ではすでに入荷しているそうなので、見かけたらぜひ読んでみてください。章構成は以下の通りです。

第1章　論理ボリュームマネージャ(LVM)を活用する
第2章　Heartbeatによるクラスタ環境の構築
第3章　DRBDによるネットワークミラーリング(前編)
第4章　DRBDによるネットワークミラーリング(後編)
第5章　高可用DBサーバーの構築
第6章　現場で使われる高可用構成
第7章　DBサーバーのパフォーマンス概論
第8章　インデックスのチューニング(前編)
第9章　インデックスのチューニング(後編)
第10章　DBサーバーのハードウェア選定
第11章　SSDの効果とアプリケーションへの影響
第12章　メモリ管理とスワップ領域の制御
第13章　ファイルシステムとI/Oスケジューラ
第14章　Linux-DBサーバーにおける負荷テストの心得



　本書籍は、DBマガジンでの連載記事「Linux-DBサーバー構築入門」と一部の特集記事がベースになっています。連載中に書くことのできなかった、SSDの章とメモリの章については新規に書き下ろしています。それ以外の章についても、書籍としての一貫性や、最近のトレンドに追従できているかといった観点から、大幅に加筆修正を行いました。
　大きく分けて、HA構成編(1章-6章)とパフォーマンス編(7章-14章)の2本立てとなっています。Linux上にRDBMSをインストールして使うのは当たり前に行われているので、そこから一歩進んで、HA構成をいかに安価に構築し、かつパフォーマンスを出していくかという点に焦点を当てています。
　主に想定している読者としては、Linux上でのRDBMSのインストール方法を知っているという前提知識があって、高可用環境の構築や高パフォーマンスのための技術を学びたいと考えている方になります。相当丁寧に書いたつもりなので、「入門」のタイトル通り、これから学ぼうと考えている方に読んでほしいです。一方で随所で踏み込んだ解説をしているので、中～上級者の方にも得るものがあると思います。


●HA構成編の内容
　HA構成編では、LVMについて軽く流した後、もっとも基本形と言えるアクティブ/スタンバイ構成から解説を始めています。まず理論をしっかり理解するという観点から、アクティブ/スタンバイ構成を正しく組むためのハードウェア設計や、監視経路の整備、Heartbeat、DRBD、monといった各ソフトウェアの存在意義の解説をしています。その上で、具体的なアクティブ/スタンバイ構成の組み方や、パラメータ設定上のポイント、フェイルオーバーテストの方法、パフォーマンス上の考慮ポイントなどをカバーしています。HA環境はただ構築して終わりではなく、その後も使い続けるものですから、トラブル時に迅速に原因を切り分けて復旧するためにも、より本質的な理解を得たいところです。特にDRBDについては、dopdやActivity Log、スプリットブレイン自動検知機能の存在意義や動作原理など、ほとんど語られることが無いけれども重要な点も解説しています。

　最近のトレンドでは、ハードウェアのうち1台が無駄になってしまい、かつダウンタイムが長くなってしまうアクティブ/スタンバイ構成から一歩進んで、どちらもアクティブ状態になるアクティブ/アクティブ構成を採用するケースが増えてきています。アクティブ/アクティブ構成については、本書ではMySQLを例にとって、レプリケーション、MySQL Clusterなどによってどんな構成が取れるかを示しています。一般的に推奨されないと考えられているマスター/マスター型のレプリケーションが使われるのはなぜか、データセンター間のレプリケーション構成は取れるのかといった点から、次期バージョンで期待を集めているセミ同期レプリケーションの可能性と注意事項などもカバーしています。第6章はMySQLに特化した章になっていますが、ほかの章についてはできるだけMySQLに依存しないように配慮しています。
　特にアクティブ/スタンバイ構成とアクティブ/アクティブ構成は、ソフトウェアの構成要素がまるで変わってくるので、特に理解が難しいポイントでもあるのですが、全体像を理解できるように配慮したつもりです。


●パフォーマンス編の内容
　パフォーマンス編では、「アプリケーション全体のアーキテクチャ」「RDBMS単体チューニング(主にインデックス設計)」「Linux/ハードウェア周り」「負荷テスト上のポイント」という観点から記述しました。
　目標スループットを達成する上で「1台のDBサーバーでは十分でないケース」が増えてきています。このときの対処手段としては、レプリケーション構成を用いたり、アプリケーションパーティショニングを組んだり、memcachedのようなキャッシュサーバを導入するといった様々な方法があります。これらは、それぞれ向き/不向きがありますが、本書を読むことでその特徴がより深く理解できるのではないかと思います。
　インデックスについては2章構成としており、前半は参照性能を最大化するためのインデックス設計、後半はINSERT性能のダウンを緩和するためのさまざまなテクニックをカバーしています。インデックスがあると更新性能が落ちるのはよく知られた話ですが、それがどの程度になるのか、データ量が増えると更新性能が落ちるのはなぜか、またハードウェア環境やテーブルパーティショニングなどによってどのように変わるのか、といった定量的な指標を示しており、参考になることでしょう。
　Linuxという観点ではメモリ制御/スワップ、メモリアロケータ、I/Oスケジューラ、ファイルシステムといった、パフォーマンス上重要なポイントをカバーしています。スワップサイズをゼロにすると何がまずいのか、接続パラメータにメモリ領域を割り当てすぎるとどんな副作用があるのか、cfq/deadline/noop/anticipatoryという4種類のI/Oスケジューラにはどんな違いがあるのか、といった、DB管理者であればひととおりおさえておきたい点をきっちりカバーしたつもりです。
　ハードウェアという観点では、HDDとRAID構成上のポイントやライトキャッシュの重要性、そしてSSDについてカバーしています。SSDには1章を丸々割いており、SSD製品選定上のポイントや、さまざまな条件によるHDDとSSDの性能差の紹介、ファイルによって適正がどう変わるかを見ていきます。そして、SSDが今後普及することで、RDBMS自体やアプリケーションにどのような影響があるかを考察していきます。SSDの章は、先月発売のDBマガジン誌の記事とほぼ同様なのですが、本書では字数制限が基本的に無いので、DBマガジン誌では書ききれなかった内容についても触れています。
　最後に、これらの要素技術を踏まえていかに実戦に活かすかという意味で負荷テストのケーススタディを紹介しています。

　MySQLを使われている方はもちろんのこと、そうでない方でもLinux上でDB構築/運用をする方であれば、必ずや得るものがあるだろう思います。
　本Blogでは、発売後しばらくの間、本書の内容を補完する意味でのサポート記事をいくつか投稿する予定です。