熊崎 宏樹:基礎を学びましょう。 CPUやOSの仕組み、そしてそれを利用して動くRDBMSはどういう原理なのかを学べば「なぜインデックスを張ると速くなるのか」などは自明に感じられるようになります。 何がわからないのかがわからない場合、経験上では対象物に対する脳内モデルが完成していません。脳内モデルというのは常に完璧でなくても構いません、これまでに学んだ知識と実際の挙動について自分なりに納得の行く説明をつけられるようにすることでモデルの精度を高めていく事ができます。そして眼の前のソフトウェアが自分のモデルから乖離した動きをするたびにそのモデルを修正する、そのサイクルをアマチュアもプロも回し続けています。 脳内モデルといっても大仰なものではなく、例えば自動車を運転していれば「ハンドルを回せば前輪の向きが変わる」とか「走るにはガソリンが必要」とか「アクセルを深く踏むと速くなる」ぐらいの挙動に対して説明がつく程度の解像度でなら誰しもが無意識に脳内に持ち合わせているはずです。自動車の中身を生業にする人でないなら深入りする必要はありませんが、自動車のエンジニアとして生きていくのであればそこから深入りしていく必要があります。 ここでまた僕の好きな本である「禅とオートバイ修理技術」から一節を引用します。 > そもそも彼らがオートバイに乗り始めた動機というのも、新鮮な空気と陽光に満ち溢れた田舎へ出かけてゆくことによって、テクノロジーから逃れることであった。ようやく逃げのびたと思っているそのときに、再びその場でテクノロジーを持ち出されることは、二人にとってひどく意気をくじかれることになるのだ。だからテクノロジーに関する話になると、いつも会話が途切れて、冷たい空気に包まれることになるのだ。（中略）明確には定義し難いが、テクノロジーを生み出すある種の力、いわば非人間的なもの、機械的なもの、生命を持たないもの、目に見えないモンスター、死の力、といったものがその正体であろう。彼らは決して逃れられないと知っていながら、何かそうしたぞっとするようなものから駆け足で逃げているのである。 テクノロジーとの向き合い方ひとつとっても、この二人（ジョンとシルヴィア）のようにテクノロジーの詳細からは逃げ続ける生き方もあります。しかし、ソフトウェアエンジニアとして生きていくのであればテクノロジーという非人間的で機械的な目に見えないモンスターと戦う覚悟を持ち合わせる必要があります。幸いなことにこのモンスターとの戦い方については定石があります。 「どうすれば自分がわからない部分を言語化して自分で解決して理解できるようになるか」という問いに対してですが、わからない部分を言語化する為のフォーマットを持ち合わせてないに過ぎないのではないかと思います。つまり物事がわからない時に「わからない」とだけ言うのではなく例えば「今の私の理解が正しければ○○になるはずなのに、実際のところは△△していて変だ。私の理解のどこからが間違っているのかがわからない」と言い換えるように努力してみてください。そうする事でその「理解」のどこから現実とのズレがあるかを探索するステップに進む事ができます。 ソフトウェア開発中に遭遇する謎挙動のほとんどは経験上使っているライブラリやフレームワークや言語に対する理解の欠如であることが多く、それらを深堀りしていくと遅かれ早かれOSなどの低レイヤーな問題にぶつかります。そこに対してもさらに深堀りを重ねていけるエンジニアこそが質問者様のいう「限界」がより高いエンジニアです。その低レイヤーを学ぶためにはつい最近発売されたBinary Hacks Rebootedが大変おすすめなので是非手にとってみてください。

熊崎 宏樹:ソフトウェアエンジニアの仕事について誤解があるようです。 確かに書けと言われた題材を動くまで持っていく力は大切ですが、それよりもっと大切なのは動いている物を思い通りにする力です。ソフトウェアエンジニアの仕事の9割以上は既に書かれているコードに対して何らかの変更を加える事であって、どこをどう書き換えるべきかという疑問に対して生成AIが具体的かつ正確な答えを返す事は稀です。 敢えて主語を大きくしますが、エンジニアの仕事というのはだいたい「既に何か動いている物があって、それが思い通りではないので何とかしたい」がスタート地点であり、生成AIが得意とする「自然言語で指示が与えられた物をゼロから作る」ではありません。 エンジニアとして働きたい者としては生成AIを敵視するのではなく、エンジニアの仕事の解像度を高め、生成AIが苦手とする分野を理解してうまく付き合っていきましょう。 「禅とオートバイ修理技術」という本から僕が特に気に入っている部分を引用します。 > (3)は、実験と呼ばれる科学的手順であり、ロマン的な人間は、時としてこれを科学そのものであると思い込んでしまう。というのは、科学的な方法のなかで、唯一視覚によって捉えられるものが実験だからである。彼らが見ているものは、数多くの試験管や、妙な形をした器具や、数々の発見を成し遂げるために忙しく動きまわっている人々だけで、その実験を雄大な知的プロセスの一環としては見ていない。だから実験と証明を混同して、それらが同じものだと思ってしまうのだ。五万ドル相当に及ぶフランケンシュタインの実験器具を陳列して、世間をあっと言わせるような科学ショーをやってのけるような人物は、たとえその結果がいかなるものになろうとも、決して科学的な実験行為を行っているとは言えない。だが一方、バッテリーの具合を調べるために、ホーンを鳴らして確かめようとするオートバイの修理工は、正式とは言えないが、実際科学的な実験を行っていると言える。すなわち生じた問題点をもとに、一つの仮説をテストしているのである。「実験は失敗に終わった。期待通りにはいかなかった」というせりふは、テレビドラマに登場する科学者がよく口にする不幸なせりふだが、実はこの不幸の原因は、お粗末な台本作家にあるのだ。予想した結果が得られなかっただけでは、決して実験が失敗したことにはならない。実験が失敗に終わったと言えるのは、さらに、問題となっている仮説が十分にテストされなかったり、また実験によって得られたデータが何ひとつ立証に値しない場合に限られる。 生成AIによってたちどころに何らかの生成物が得られても、それは科学ショーに過ぎません。科学を構成する仮説の立案と検証を繰り返す雄大な知的プロセスの中においては生成AIがサポートできるのは一部に過ぎません。特にプログラミングに限って言うとブライアン・カーニハンによるこんな名言もあります。 > “The most effective debugging tool is still careful thought, coupled with > judiciously placed print statements.” — Brian Kernighan, “Unix for Beginners” > (1979) > > 最も優れたデバッグツールとは依然として注意深い思考と組み合わせて慎重に配置されたprint文である。 ブライアン・カーニハン, "初心者のためのUnix" > (1979) この本は古いですが依然としてソフトウェアエンジニアリングにおける重要なポイントを示唆しています。眼の前のプログラムが自分の思った通りに動いてくれない事はプログラマにとっての日常です、そこで何故思った通りに動いてくれないのかを具体的に立証する方法を立案する過程を生成AIは教えてくれません（デバッグに関する一般的な事は教えてくれますが）。たくさん学習させたら帰納的にできるようになるかも知れませんが、それを学習させようにも製品コード自体がそもそも膨大ですし、仮説と被疑箇所に基づいたprint文なんて製品コードには残っていないので学習する為のデータセットを集めるだけでも一苦労です。よって「眼の前のプログラムを望む仕様通りにしてくれる」という生成AIが登場するのはずっと先ですし、仮に仕様通りに動いてもそれを確認するテストやQAの仕事が生成AIに取って代わられるのは更に先の話です。 まとめると、僕の意見は「科学的手法(仮説立案・実験・考察)を身につければ少なくともしばらくは生成AIにとって代わられない仕事ができる」です。

熊崎 宏樹:キャリアのために今から学位を獲得すべきか？という質問ですね。短い答えは「ノー」です。なぜならビッグテックは学位を採用条件にしていません。実際の求人をいくつか見てみましょう。ソフトウェアエンジニアリングの求人を適当にピックアップしたのであなたがこの文章を読む頃にも同一の求人がアクティブかはわかりませんが、傾向は変わらないはずです。 ビッグテックの求人例 まずはGoogleはこうなっています。 > 学士号を取得していること（同等の実務経験でも可） 次にAppleは学歴に関する言及すら無くMinimum Qualificationsには > * 2+ years of experience in web application development with an in-depth > understanding of data structures and algorithms. とあります。つまり実務経験ということで他の項目は言語やフレームワークの経験ですね。 次にFacebookことMetaは > * Bachelor's degree in Computer Science, Computer Engineering, relevant > technical field, or equivalent practical experience コンピュータ・サイエンスやコンピュータ・エンジニアリングやそれに関連する技術領域の学士、もしくは同等の実務経験と書いています。実務経験が説明できれば学歴での足切りはありえません。 そしてAmazonはPreferred Qualification (=あると望ましい資格)の所に > * Bachelor's degree in computer science or equivalent とあります。コンピュータ・サイエンスの学士号もしくは同等の学位、と言っているようですがあくまでPreferredなので足切りではなく加点ポイントですね。 Netflixの求人も見てみましたがrequirementに関する言及すらありません。 Microsoftのソフトウェアエンジニアリングは > * Bachelor's Degree in Computer Science or related technical field AND 2+ > years technical engineering experience with coding in languages including, > but not limited to, C, C++, C#, Java, JavaScript, or Python > > * OR equivalent experience. とあって、同等の経験(equivalent experience)があれば学位は無くても良いと明記しています。 書類選考について 実例を並べても「暗黙の条件が別にあるんじゃないの？」と疑うのもわかりますが、僕の知る限り求人票におけるこういった条件は本当に文字通りの解釈をするために用意されています。「ソフトウェア開発の2年の経験」と書いてあれば2年間ソフトウェア開発部署でただ椅子に座っていただけでも一応満たしますし、逆にNext.jsやDockerやクラウド技術をバキバキに使い倒したアプリとかOSとかコンパイラとかDBを1人で作りましたとポートフォリオに並べても実務経験を書いていなければ「実務経験1年同等」とすら解釈されず落とされます。 テック各社、書類選考のレイヤーでは候補者が多すぎるので機械的に該当しない人をminimum requirementsに照らしてその後の選考に進む人を選びます、ここに関しては落ちたらそういうフィードバックが貰えることもあるのでリクルーターに聞いてみると良いです。満たしているのに書類で落ちた場合は運です、学位を持っていても運悪く書類落ちすることはザラです。書類選考に対しては学位よりもリファーラルを受ける方が有効に働くと思います。 そして二次選考は主に（特にソフトウェアエンジニア職は）面接を通して行うのでそこで高評価が出せるかがとても大事です。最終決定の際に複数の候補者の間で決め兼ねた時に何を手がかりに決定するかは会社によっても違うので学歴も見るかも知れませんが、大抵は別のシグナルを用いて決めるはずです。ですのでビッグテックにおいては学歴にこだわるよりは同等の実務経験を積むほうが就職に対して合理的であると思います、学費も掛からないし給料も貰えます。 また、年齢についても各社の求人ページをよく読んでみると気にする必要がないことがわかります。例えば上のGoogleのページだと > また、人種、信条、肌の色、宗教、性別、性的指向、性同一性またはその表現、国籍、障がい、年齢、遺伝情報、従軍経験、配偶者の有無、妊娠またはそれに関連する状態（授乳を含む）、親になる予定、犯罪歴（法的要件に一致する場合）、法律によって保護されるその他の状態にかかわらず、均等な雇用機会を提供すべく尽力しています。 Metaだと > We do not discriminate based upon race, religion, color, national origin, sex > (including pregnancy, childbirth, reproductive health decisions, or related > medical conditions), sexual orientation, gender identity, gender expression, > age, status as a protected veteran, status as an individual with a disability, > genetic information, political views or activity, or other applicable legally > protected characteristics. ほぼ同じような事を書いています。わざわざ書きませんがAmazonもAppleもNetflixもMicrosoftも同様の文言が書いてあります。 なぜこれらを明記しているかと言うと、もし仮に年齢による足切りが暗黙にでも行われていた場合、それはアメリカでは人種差別や性差別と同様に違法だからです、場合によっては性別や年齢入りの履歴書を提出した際にリクルーターから消すよう依頼される事すらあります。ですので「進学したら年齢が高くなり過ぎてしまうのではないか」という懸念も不要なものです。むしろOver Qualified（過剰資格）の方が先に問題になるかも知れません。 ただし、研究職に就くのが目的である場合は論文投稿・発表実績などが加味されるため大学の研究室に所属するのが正攻法になる事もあるかと思います。 コーディング力と面接対策 AtCoder黄というのでアルゴリズム力に関しては特に不安は無いですが、コーディング面接で問われる能力はアルゴリズム力だけではありません。面接は面接でコツが要るので米国では定番の「Cracking the Coding Interview」（邦訳: 世界で闘うプログラミング力を鍛える本 ）を読んでおく事をおすすめします。オンラインで有料で面接練習ができるサービスも幾つもありますし、知り合いの経験者と模擬面接をして練習するのもおすすめです、僕に直接コンタクトをとっても歓迎です。知り合いが運営している「Engineer Guild」も何かの力になれるかと思いますし無料です。暖色コーダーでも落ちる一方で灰色コーダーでもコツさえ掴めば通るのが面接ですので入念に準備することをおすすめします。 どの会社も「仕事ができる人を採りたいが直接それを測れないので面接でアルゴリズム問題を出して近似している」が実態であって、面接では仕事ができる人であることを示す事が大事です。例えば難問に直面した時の理想的な仕草は「ダメ元でセグメント木を取り出して振り回す事(AtCoderでは意外と有効)」ではなくて「何が問題の核心でどんな道具があったら解決できるか自分の考えを整理して説明する事」だったりします。その差を理解するために場数を踏む以上の方法を僕は知りません。 進学の是非 もちろんコンピュータ・サイエンスの基礎から体系立てて学ぶ事自体は有益ですので熱意が持つのならぜひ進学すると良いと思います。ただし入社に向けての準備ではなく、入社後のキャリア形成の一環として会社から補助を受けながら進学するのがおすすめです。多くのビッグテックがそのような社員特典を用意しています。 https://www.levels.fyi/benefits/Tuition-Reimbursement/ もちろん働きながらの学業は忙しくなりますがそれだけの価値はあります。

熊崎 宏樹:アメリカの大学でCS。すごいですね、アメリカでもCSの人気は高まってて競争が激しいと聞いています。 数学を勉強していなくてセンスに自信が無いとの事ですが、大丈夫です。僕も数学は実はからっきしで、高校で3Cまで習いはしたのですが合成関数の積分あたりからテストでまともな点が取れなくなりました。大学の微積やら線形代数の授業なんかも参考書の付け焼き刃で乗り切ったに過ぎず、どこまで身についているか怪しいものです。 GAFAMで活躍している人にセンスがある、というのは正しいかも知れませんが、働いている全員にセンスがあるとは限りません。少なくとも僕自身は日々コードを書きながらセンスの無さに打ちひしがれているからです。何かすごいフレームワークとライブラリで動いているのはわかるけれどそのフレームワークの気持ちがまるでわからない、Dependency Injectionされた値がどこで取りこぼされているのか、出力したはずのエラーログが出てこない理由は何か、さっきと同じ手順で投げた同一のクエリの結果がまるで異なるのは何故か、connection refusedというログの裏の理由とは？コンフィグ内の識別子と自動生成された変数とフレームワークの引数が複雑なビルドの向こうで空中合体していることはわかるがそこで起きたコンパイルエラーは何が不満なのか、わからないことだらけの脱出ゲーム状態で試行錯誤しながら日々過ごしています。これは合成関数の積分ができれば理解できるタイプの問題ではなく、フレームワークの仕様や挙動を忍耐強く学んで活用していく事が王道です。これに対して才能がある人というのはおそらくゲームが得意な人なんだろうと思います。僕自身もゲームは人並みに得意なつもりでしたが脳の情報処理能力の限界を日々まざまざと見せつけられるような気持ちです。そうして毎日仕事終わりには「向いてないな…」とか嘆きながら席を立ちます。 さて、才能が無いなら諦めるか、という話に戻すと「才能を理由に諦めるなんてとんでもない」が僕の答えです。僕が持っていると堂々と言えるような才能は「毎日12時間はディスプレイに齧りついていられる視力含む身体的強度」ぐらいのもので、センスとか頭の良さといった観点では常時ついていけなくて悶絶しております。アメリカの大学でCSを学ぶ程に根性があるのであればその時点で僕の学生時代より遥かにアドバンテージを取れています。 微分積分の授業は参考書に齧りついていれば誰でも点が取れるようになりますが、人が後天的に「自分が書いたコードが動いた時に快感を得る」ように鍛錬することはまず無理であり、立派な才能です。「好きな事を仕事にできたら良さそうだし深堀りしてみよう」ぐらいのモチベーションでしばらく没頭し、目安的には10000時間ぐらい使ったあとで改めて考え直しても充分な程にまだまだあなたの人生には時間があります。あなたが就活する頃にはひょっとしたらもうGAFAMではなくもっと魅力的な会社が台頭しているかも知れませんし時代の流れに上手く乗れたらもっと素敵な仕事ができると思います。学んだCSの知識があと50年は無駄になることは無いでしょう。 就活は一期一会ですし現在の情勢でGAFAMに入るには単純な能力ではなくてタイミング良く狙ったポストに空きがあるかのほうが遥かに重大です。僕が入社できたのもひとえにタイミングのお陰でした。時流の流れに積極的に目を向けていきましょう。

熊崎 宏樹:RDBMSが流行った理由はトランザクションのお陰ではありません。何故ならリレーショナルモデル登場前からトランザクションをサポートしたデータベースは複数あったからです。 リレーショナルモデルの提唱者であるEdgar F. Codd氏がその当時勤務していたIBMが売っていた製品がInformation Management System(以下IMS)というデータベースで、階層型データモデルというデータ型でデータを表現していました。これは例えるならファイルシステムのディレクトリ構造とファイルのようなもので、同一の物を複数の階層から参照することすらままなりませんでした(その欠点を改善したネットワーク型モデルというのもあります)。また、データにアクセスする際にはそのデータのフルパスに相当する情報をプログラマが管理した上でアクセス手順をプログラムする必要がありました、そうやってアクセス手順を案内する必要があるという点でナビゲーショナルデータベースシステムという呼び方をされることもあります。 データベースのリカバリ戦略を特徴付ける4つの観点「複数ページの更新を一括で行えるか(≒シャドーページング等の有無)」「トランザクション実行途中のDirtyなページのディスク書き戻しを許すか」「コミット時に全ページの書き込みを強いるか」「チェックポイント戦略」において分類木を作ると左端に『ページはその場で更新・Stealあり・Forceする・コミット時に全部ディスクに強制的に書き出すから明示的なチェックポイントは要らないよね(=Transaction Oriented Chcekcpoint)戦略』IMSが分類されています。またIMS Fast Path (FP)は「ページはその場で更新・Stealなし・Forceしない・チェックポイントを取ると決めたら新規トランザクションを全部止めて今居るトランザクション全部終わるのを待って全ページFlushしたら良いよね(Transaction Consistent Checkpoint)戦略」で現在で言うIn-Memoryデータベースの源流と呼べる場所にいます。 右から3つ目の『複数ページ一括更新する・Stealあり・Forceなし・書き込みが無いタイミングで全ページFlushしたらリカバリが速い(Action Consistent Checkpoint)戦略』のところにSystem Rが居て、これはシャドーページングを使っている事でも有名なRDBMSです。 RDBMSのリレーショナルデータモデルがCodd氏から提唱されたのが1969年(論文が外に出たのは1970年)とされている中で1960年代からIMSを始めとして多くのシステムがトランザクションの永続化と一貫性について試行と改善を繰り返して来ていました。RDBMSのトランザクションの仕組みは既存の研究の一種に組み入れて論じることができる程度には一般的なものとなっていたと言えます。 さて「なぜRDBMSが主流になったか」という当初の疑問に対してよく言われているのは「OptimizerとIndexの進化」です。最初期の頃のRDBMSは研究もそこまで進んでおらず、速度面で大きなビハインドがあったためナビゲーショナルデータベースシステムの地位を脅かす物だとは思われて居なかったのですが、関係代数を基盤にした様々な最適化やインデックスによるアクセス高速化によって、手作業で職人芸めいたアクセス高速化をしなくてはならなかったナビゲーショナルデータベースシステムよりも市場に受け入れられ、最終的にナビゲーショナルデータベースシステムの最大手だったIBMがRDBMSに本腰を入れ始めたあたりから市場の大勢が固まったと認識しています。開発にかかる経済コストはこの話題における重要な要素です。 リレーション(いわゆるテーブル)の形でデータを保持すると直感的だから受け入れられたというのもそれなりに説得力があると思いますが、それでも外部キーによってテーブル間の連結関係を表現する際に整数を用いているのは印象的です。「データ独立を実現したことにより変更容易性が高くなり生産性が上がった」という点で思い出したのですが、誰かが「キーが整数ならバイナリの塊からでも人力でデータが復旧できる」という仮説を提唱しているのを聞いたことがあります。外部キーとは他のテーブルの特定の行に対する参照なのだから原理的にはポインタとかオフセット値とかもっと物理的な情報をkeyとしたほうが間接参照の回数が減るので高速化するのは確実なのですが、それをやってしまうと物理的な故障が起きた際にデータをダンプして目視で復旧する際の難度が跳ね上がってしまうので敢えて整数値による間接参照によってそのレイヤーでの柔軟性を保持することでシステム更新時のコストを抑えているという仮説です。歴史に埋もれているだけで実はハードディスクの更新などを契機に壊れてしまい復旧に多大なコストを払うことになったシステムもあったのではないかと想像しています。

熊崎 宏樹:ペアプロ・モブプロは楽しいですね。特に慣れないコードベースや言語やエディタでの習慣や作法についてコードそのものからはわからない情報が得られる点に最大の利得があると感じています。 しかしコードを属人化させないという観点ではレビューを徹底する事でも解消できますし、設計の議論を深めたいのであれば共有でオンラインなドキュメント上でコメントを応酬しながらやりあったほうが最後に記録が残り第三者が見返す事もできます、更には物理的に近い場所にいる必要もなくタイムゾーンが合わない人とすら時間的な拘束なく協力ができるので結構な利点があります。 逆に言うとペア・モブプロは記録が残らない上に時間的な拘束が発生するので最強とまでは言えないのではないかと思います。プログラマ同士で実力差がある場合のキャッチアップには便利ですが、全員それなりにシニアならそれぞれ別のコードとドキュメントを書いて他人がレビューする体制を回す方が全体としてのスループットは高いと感じます。

熊崎 宏樹:普通のプログラマとしての素直な感覚ではむしろその「奔放な変数宣言」の方が良いです。 コードを読む時は未知の識別子が出てくるたびに認知負荷が高まっていく訳ですからグローバル変数を始めとして内部から参照できる変数は少ないに越したことはありません。関数が1画面に収まるサイズならスコープの開始位置という決まった場所にあれば変数の宣言もすぐに確認できるというのは一理ありますがシリアスなコードを書いていれば1画面に収まらない関数というのはザラに出てきます。 特にC++のようにオブジェクトの生成自体に意味を持たせる事がある言語（例えばscoped_lockなど）においては宣言と生成を分ける方がアンチパターンでありRAII(Resource Acquisition Is Initialization)という言葉にも現れています。C99を策定する頃はJavaなども台頭してきておりそれらの良い所を適宜取り入れていくノリでスコープの先頭以外での宣言も許されたのだと思います。forループのカウンタのiなんかはループの外で触ってしまったら事故の元ですし、ループ外で触ったらコンパイルエラーで教えて欲しいです。スコープを細かく区切れるようにしてそこでの変数宣言は上に寄せたほうが良いというのは確かにそうだと思いますが、宣言が初期化を兼ねている方が読みやすいコードである以上は宣言位置をブロックの先頭に限定しないほうが柔軟な活用ができます。 そもそもがC89においてスコープの先頭でしか変数を宣言できなくしていたのは、その関数が使用するスタックのフレームサイズを早期に確定したいとかコンパイル中の識別子テーブルの実装を簡単にしたいといった実装依存の理由が強く、書かれるコードの品質の側面では特にメリットはありませんでした。 一方で「奔放な変数宣言」を許すと画面内のコードの塊の中で依存関係が完結しているケースにおいて読みやすくなりますしコピペしたらそのまま動くことも多いです。コードのコピペと言うと急に素人のやっつけ仕事っぽい印象がありますが、プロだって必要に応じてどんどんコピペを活用します。コード片のモジュール性が高い事の恩恵というのは日頃からデカいコードの上で仕事をしている人のほうが有り難みを感じるのではないかと思います。

熊崎 宏樹:和訳されているC++本はだいたいどれも大きなハズレではないのですが、僕がC++を学んだ時は定評のあるEffective C++から入りました。基本的な言語機能は適宜検索すればわかるので、どういうコードを書くべきでないかという観点から入れたのは自信を持ってコードを読み書きするには良いスタート地点でした。 https://www.amazon.co.jp/dp/4621066099 Effective C++の中には今（C++11以降）となっては必ずしも通用しないベストプラクティス（使える場所ではconstにしよう、など）もあるのですが、なぜ過去は推奨されておりなぜ現在は推奨されていないかを把握したほうがより良いコードが書けるので古典から入るのはおすすめです。特にJVMもV8もBlinkもC++11以前から続いているプロジェクトなので古いベストプラクティスを学ぶ事はそれらの理解の助けになります。 この原著者のスコット メイヤーズ氏の著作はどれもとても良くて、C++11/14以降でアップデートされた本（Effective Modern C++）も書いています。こちらもとても評判が良いようです。 https://www.amazon.co.jp/dp/4873117364/ Exceptional C++はC++で例外を使うのがいかに難しいかを本一冊かけて滔々と説いています。C++は言語レベルでガベージコレクションを持たない言語ですが、そこの上では例外を使うといかに発見が困難なバグを埋め込むかという事をこれでもかというほど書いています。人によってはこれを絶対読むべき本として挙げる人もいます。 https://www.amazon.co.jp/dp/4894712709 C++テンプレートテクニックは上記の本ではあまり解説されていないテンプレートの技法をたくさん説明していて良かったです。SFINAEとかType ErasureとかCRTPあたりのテクニックはそれなりに大規模なC++プロジェクトでは常識のように使われているので、自分でゼロから書けなくても「なんか上手いこと行ってこうなるらしい」という事だけわかっていれば読む際にはどうにかなります。 https://www.amazon.co.jp/dp/4797376686 本に限らずともC++を学ぶために有益なリソースはオンラインに無料で転がっていてGoogle C++ Style GuideはGoogle社内でC++を書く際の決まりごとです。ただのルールが列挙されているだけではなく、何のためにこうするのかという目的も逐一簡潔に書いてあるので勉強になります。またV8はGoogle C++ Style Guideに準拠して書かれているはずなので学んでおくと理解の助けになります。有志による日本語訳もありました。オンラインで全部読めます。 https://ttsuki.github.io/styleguide/cppguide.ja.html 最近僕が読んでいる物でいうとC++ソフトウェア設計という本がかなり良いです。デザインパターンというものがいかに誤解されているか、そしてC++20時代に於いてなお重要なパターンとその効用に絞って説明している稀有な本です。特に良いのが、パターンや言語仕様の説明のようなテクニカルな要素ではなく、大規模コードとその拡張可能な設計に焦点を当てる事を意識した本であるという点であり、これは血の通った知見であると感じています。SOLID原則について良くある誤解を例を挙げながら解説し、一つのデザインパターンでも実装上の選択肢があり、逆にほぼ同じコード構造でもプログラマの意図によって別のデザインパターンたりうる事を説明しています。駆け出しのプログラマがデザインパターンを使いこなすのは至難の技ですが、質問者様が挙げられているプロジェクトはそれらを使っているので読む際に何を意図したコードなのかを把握する手助けになります。 https://www.oreilly.co.jp/books/9784814400454/ C++にはRAIIとかRTTIとか略語が大量にあって僕も未だに知らないものがいっぱいあってこれを眺めているだけで面白いなぁと感じています。 https://quuxplusone.github.io/blog/2019/08/02/the-tough-guide-to-cpp-acronyms/

熊崎 宏樹:まずログ構造化ストレージというのはアルゴリズムの一種であって特定のハードウェアやデバイスの事を指しません。また、ログ構造化というテクニックに関して言うとSSDの内部でフラッシュメモリのコントローラが利用するケースやブロックデバイスが使うケース（e.g. Log-Structured Block Device）やファイルシステムが使うケース（e.g. RFS）やデータベースライブラリが使うケース（e.g. LevelDB）など様々あります。 永続性と応答速度を両立しようと思った時に一旦書ける場所（ログ）に書いてしまって完了を報告し、後で正しい場所に書き直そうという戦略はジャーナリングなどとも呼ばれ、様々なレイヤーで古くから活用されてきました。しかしそれだと最低でもWrite Amplifier（論理書き込み1回に対して物理書き込みが何回起きるかという倍率）が常に2を超えてしまってスループットが犠牲になります。なのであわよくばログに書いたまま書き移す事なくメタデータを工夫して参照の際にうまく取り回す事（構造化）でどうにか性能のバランスを取ろうというのがログ構造化ストレージの基本思想です。 しかし前述したようにあらゆるレイヤーで似たような事を多重に行うのはあからさまに無駄が多いのでそれを解決するためにはアプリケーションからデバイスまでで一貫した戦略をとったら良いんじゃないか等と研究（e.g. Don’t stack your Log on my Log）されており目が離せない分野です。例えば必ずSSD上でしか動かさない前提のシステムであればファイルシステムやアプリのレイヤーで書き込みをシーケンシャルにするよう拘る意義が薄れますし、DBアプリから見たストレージシステムの方で書いたデータがフラッシュメモリに書かれるまでを垂直統合して最適化したら良いんじゃないかなんて過激な研究もあります。 https://dl.acm.org/doi/10.1145/3514221.3526188 さてストレージのヘッドの話に興味があるようなのでHDDの話をしたいのだと思います。複数のプラッタを持つHDDはプラッタの枚数に比例して読み書きヘッドが増えるので「読み書きヘッドが複数ある」とは言えますがそれらは独立して動くことはないのでスループットには関係ありません。 HDD上のLSM-Treeの上で読み込みが発生して問題ないかというと、もちろん悪影響があります。ちなみに書き込み命令と読み出し命令が複数個キューに積まれた時、それをどの順序で最終的に実行するかは下のレイヤーでうまくディスクヘッドのシーク量が少なくなるよう並べ替えて実行されます。なので最終的に読み書きがどういう順序で実行されるかに付いてはアプリのレイヤーからは制御しきれません。 https://en.wikipedia.org/wiki/Native_Command_Queuing シーケンシャルな領域への書き込み命令自体が連続している場合はヘッドの移動は最小になるためもちろん最良の性能が出ますし、readが入るとヘッドシークに約10msかかるので書き込みのスループットにも悪影響は出ます。と言ってもLSM-Treeの書き込みのスループットは最良ケースであってもマージ操作の際にガタ落ちするのでReadによる外乱はそこまで致命的ではないと思っています。SSD等であればなおさら影響は減ります。 LSM-TreeのReadに関してはメモリを使ってキャッシュするのが基本戦略です。メモリ内の問い合わせによってヘッドシークの回数を減らせば減らすほど良いのでBloom Filterを用いて不在判定を高速に行うのが定番です。LSM-Treeの各レベルごとにBloom Filterを取り付けておき、不在判定に失敗した場合はそのレベル内のペイロードの実スキャンを行うのですが低レベルでの不在判定ミスは高レベルでの不在判定ミスよりペナルティが大きいので低レベルのBloom Filterサイズに傾斜をつけて大きめの容量を振っておけば全体としてスループットが上がるというMonkeyなんかは面白かったです。 http://daslab.seas.harvard.edu/monkey/ 他にも、キャッシュする際にはkeyに対するvalueのポイントクエリの結果をLRUキャッシュなどに入れておいてもレンジスキャンの際にそのキャッシュ内容をうまく活かせれないのでレンジスキャン用キャッシュとポイントクエリ用キャッシュを適応的にバランスさせながらキャッシュメモリの有効活用を試みるAC-Keyなんて研究もあります。 https://www.usenix.org/conference/atc20/presentation/wu-fenggang 何にせよメモリを使えば使うほどRead性能が上がるという点で難しいトレードオフがあります。LSM-Treeに興味があるのであれば僕のブログ記事もあなたの知的好奇心をくすぐるかも知れません。 https://kumagi.hatenablog.com/entry/end-of-freezing-lsm-tree 以上参考になりましたら幸いです。

熊崎 宏樹:できます。 むしろ「データ指向アプリケーションデザイン」ではそういった方向性を推奨しています。Redoログだけ何らかの手段で強固に永続化されていれば、そのログの永続完了を分水嶺にして個別のトランザクションのロールバック・ロールフォワードを決定できるようになり、分散DB全体の原子性を実現する事ができます。 MicrosoftのSocratesはこの方向で詳しく書いているので参考になると思います。 https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf システム図を引用すると以下です。 このXLOG SERVICEと書いてあるブロックの部分でログを永続化し、ページサーバーで必要なログを分配してページ情報をXStoreに置いています。このXLOG ServiceのLanding Zoneは3多重で複製を作り続けるAzure Premium Storage serviceを利用していると論文中で明記しています。Raftが実現するReplicated State Machineはまさにこの点でぴったりマッチします。このようにRaftで複製して永続性を保証したログはリカバリに利用できます。 ただし、リカバリという観点では正しくACIDを実現したページがアプリケーションから見える事が大切であり、そのためにはログのRedoやUndoを適切に実装する必要があります。これはRaftで自明に解決できる話ではありません、部品として使うことはできても完全な答えにはなりません。 少し衒学的になりますと、多くの人はWALという言葉を使っていますがWrite-Ahead-Logが「何が何に対してAheadしているのか」という事を説明できる人は意外と少ないという肌感覚があります。正解は「ログの永続化がページの永続化よりも必ず先行する」という意味であり、ログの永続化完了までページのpinを*必ず*維持するといったせせこましい一貫性保証の細かい実現手段を表現しているのですがただのバイナリログの事をWALと呼ぶ人が多い気がしています。このSocratesの論文ではWALという単語は使われていませんし、上のFigure 2から見てもわかるようにPrimary側のページは永続ストレージに向かって直接保存される事はありません。つまり「ページの永続化」という操作自体は存在しなくて、単に永続化されたログから一方通行でページのイメージを練り上げるという操作を行っているので先行するも何もなく、この手のアーキテクチャの分散DBにおいてはWALという言葉を使わないのが適切です。これはAuroraに関しても同じことが言えます。

熊崎 宏樹:僕の専門領域ではないですがプロの方の回答が出るまでの間、門前の小僧が習わぬ経を読んでみます。 トランジスタを小さくする事はそれ自体が目的ではなく、安く高性能なトランジスタを追い求める過程でとる手段の一つに過ぎません。微細化競争ばかりが槍玉に挙げられますがそれでなくても半導体開発は（光学に限らず）現代の科学の結晶の一つです。 まず大前提として仮に原子一個レベルにまでプロセスが微細化しても一つのチップの上に何億規模でトランジスタを載せる以上はその故障率や歩留まりに関してはトランジスタ一つあたり99.999999%の良品率でも足りません。微細化が終わっても歩留まりとの戦いはほぼ終わらないことでしょう。半導体の製造過程自体を改善して良品率を上げることもあるでしょうし、一部に不良なトラジスタが入っても完全に動くように回路に冗長性を持たせる技術も改善の余地があります。 他に挙げられるのが素材の改善です。もう10年以上前になりますが高誘電率材料によってゲート絶縁膜を厚くすればリーク電流が減るというHigh-Kメタルゲートはintelの45nmプロセスのときには既に量産に入っていたとされています。 https://www.jstage.jst.go.jp/article/oubutsu/76/9/76_1006/_pdf https://pc.watch.impress.co.jp/docs/2007/1212/iedm03.htm 他にも例えばトランジスタの形自体にも工夫の余地があります。 https://ascii.jp/elem/000/000/884/884429/ これらの研究は終わったという事は無く、業界の人々はより良い素材をより良い形で量産に適した製法で製品化できるよう今も研究を重ねています。 CPUそのもののアーキテクチャも日夜改善が繰り返されており、ほぼ同一個数のトランジスタを使いながらもより高い処理性能を実現する分岐予測とか投機的実行とかSIMDとかやることは山ほどあります。 まとめると、微細化が仮に終わってもトランジスタの性能改善はまだまだ研究余地があるし、トランジスタの有効利用法に関しても大きな研究余地があります。

熊崎 宏樹:前提として世の中にあるデータベースは基本的にログファイルが破損する事を想定していません。ログは信頼できるストレージに複製込で保存されており、化けたり消えたりする事はないという前提を置いています。想定する一番大きな障害でもMedia Failureであり、これはデータベース本体を保存しているストレージがまるごと使えなくなった場合の事ですがそれでもログから復旧できると言っておりログ自体は故障の議論の範疇外です。仮に信頼できる永続ストレージが世の中にあるならそこに全DBデータを保存すれば復旧にまつわるめんどくさい議論の大半がスキップできるのにと思っているDB研究者は多いと思いますが、実情としてはログの永続化は運用レベルで歯を食いしばって実現しているようです。運用レベルでログが信頼できるとしているのでDB開発者はログ以外の部分をアルゴリズムで守るように努めています。 さてログのフォーマットをどういう形にするかというのは広大なデザインスペースがある話題ですが、アクセスしたいと思った該当ログに対しては全探索せずとも見つけられるようにするのが定番です。破損は無いにしてもΘ(N)よりは高速に任意のログを見つけたいものです。ここに関してはPostgreSQLと(僕の理解が正しければ)MySQLが採用している定番の方法があって「ログのオフセット自体をIDとして扱う」という方法です。ログに振られるLSN(Log Sequence Number)は被りが無くて単調増加さえしていれば歯抜けがいくらあっても構わないのでファイルの先頭にあるログはLSN=0だし、その一個後のログは前のログが42バイトあってその直後をスタートとしているのでLSN=42である、といった具合です。これはLSNが与えられた時にそのファイル箇所までシークすれば読めるので圧倒的に高速です。各LogにLog長を埋め込む必要もありません。 奇しくもこの方法はrecordの一部が破損してもそこから後ろのオフセットまでは壊れないという点でも頑健です、もっというと各ログにCRC32のようなチェックサムを埋め込んでおく事でログの破損を検知することができます（そこからどう復旧するつもりかは知りませんが…）。

熊崎 宏樹:これは長年いろんな研究が積まれながら結果としてあんまりパッとしていない分野です。 例えばOracleは自社のDB専用のサーバやチップを作れる会社ですし、更に高速なDBを求める顧客にハードウェアまで垂直統合させたアプライアンスのような製品を用意するのは順当な戦略に思います。SPARC M8というCPUはまさにOracleがDB用に拡張したプロセッサ機能を搭載しています。 https://www.oracle.com/technetwork/jp/server-storage/sun-sparc-enterprise/documentation/t8m8-architecture-wp-20170914-ja.pdf > SPARC M8 プロセッサには、特定のソフトウェア機能またはプリミティブを高速化するハードウェ > ア・ユニットが組み込まれています。これらオンチップのデータ・アナリティクス・アクセラレータ（DAX）ユニットは、データベース・クエリ処理をオフロードし、リアルタイムでデータ圧縮解凍を実行し、Java > ストリームを加速化します。インメモリ・クエリ・アクセラレーションは、他の プロセッサに比べて最大 7 > 倍の性能を実現します。インライン圧縮解凍機能により、パフォーマンスを低下させることなく、同じメモリ・フットプリントで最大 2 倍の量のデータを保存できます。 > SPARC M8 プロセッサの新しいコアには、Oracle Database での実数処理を高速化する Oracle Number > ユニットも組み込まれています。 非エンジニア向けの資料なので詳細は書いていませんが大まかに雰囲気は掴めます。要するにDBの内部で行われる動作の一部をハードウェア処理にオフロードする方向性のようです。DAXユニットというストリーム処理を行うコプロセッサのような物の他は特定用途のSIMD命令かアドレス自動チェック機構あたりであって、専用プロセッサだからといってあらゆる処理が桁違いに速くなるたぐいの物では無さそうです。これに需要があることは否定しませんが、DBMS専用プロセッサをゼロから作るに値する程の恩恵が万人にあるとは思いません。クラウドで安く強いx86系のCPUが使えれば大抵の用途には合致するはずです。 オフロードする、という観点でいうと今どきの大規模なデータベースはストレージとエグゼキュータが別のホストになっていることが定番で、エグゼキュータ側でトランザクション処理を実行する傍らでストレージ側でチェックポイントや永続化や簡単なフィルタ処理の一部などをオフロードされて処理する事が一般的です。DBMS専用プロセッサにその一部がオフロードできるにしても汎用プロセッサの方ができることが多いですし、充分な通信帯域さえあればオフロード先が隣のノードで構わないという戦略が経済的に勝利したと認識しています。 データベースの処理は分析処理のOLAP、トランザクション処理のOLTP、後はストリーミング等の特殊用途の3つがメインとされます。 OLAPに関してハードウェア的なリミットはほぼ無く、基本的にCPUやマシンを並べて並列度を高めれば高めるほど高速化する事が多く、その観点においてボトルネックはタスクをデータの偏りに対処しながら上手く分配するアルゴリズムや実装上の問題の方が大きいです。強いていうとソート・ジョイン・リミットなどの並列化に関してはインターコネクトで工夫をしているようです。従来はMPIが得意としていた集合通信を用いた並列処理ですが大規模なデータを巨大なクラスタの中で合理的に並列化しようと思った際にはネットワークのハードウェアのレベルから手を入れRDMAなどの力を借りて高速化する余地はまだまだあります。 例えば以下の論文はTop-KクエリをMPIを用いて高速化するというものです。 https://arxiv.org/abs/1709.05183 OLTPに関してはワークロードとしてトランザクションが衝突しまくるケースに対する根本的な解決策は見つかっておらずとにかくCPUクロックを上げるしかありません。トランザクションの衝突が問題にならないケースにおいては内部の永続化アルゴリズム自体の方がボトルネックになることが多いようです。ここについては僕のブログ記事での論文紹介もご覧ください。 https://kumagi.hatenablog.com/entry/finding-storage-glitch 永続化アルゴリズムの問題が解決した場合には恐らくディスク帯域がネックになりますが、M.2のSSDをストライピングするなどによって容易に10GB/sec以上の帯域は出せるので不揮発メモリが真に輝く時はディスクの永続化レイテンシが問題になるケースに限られ、そこへの道のりはまだまだ遠かろうという論文もあります。 https://dl.acm.org/doi/10.14778/3603581.3603586 ストリーミング処理に関しては僕はほとんどサーベイしていないので有識者の意見を待ちたいところです。

熊崎 宏樹:質問ありがとうございます。いくつか質問の内容がわからない所があったので少し考えていました。 TiDBの記事を読みましたが2PLとは書いておらず2PCとその内部での挙動に関する話でレイヤーが異なるようです。2 Phase Lock (2PL)と2 Phase Commit (2PC)は字面こそ大変良く似ていますが2PLはロックのComposabilityを応用したトランザクションの実現手法である一方で、2PCは故障を度外視したまま設計されたデータ複製に過ぎず、適用する対象も導入する目的もまるで異なるものです。 このTiDBの記事では事前書き込みリクエストを対象ノードすべてに送った後にコミットを改めて対象ノードすべてに送る2フェーズからなるので正しく2PCであるようです。そしてこれはロックの成長相と縮退相の2つから成るという点でも2PLでもあります。そして問題はこれがS2PLであるかどうかです。 > Raftの層である程度の Durability やConsistency を保証しているから2PSで十分 Raft自体にDurabilityを保証する機能はありません。Raft自体がデータを永続化し続けるステートマシンを前提としているからです。2PSというのが何なのかわからないですが2PLだとしても2PCだとしてもRaftだから十分という話にはなりません。 > 実際にはS2PLだが2PLと説明している これはこの文書に限らずとても良くあるパターンです。Strict 2PLと2PLをわざわざ分けて論じる必要がある時は永続性と一貫性に焦点を当てた話をする時であって、2PLと書かれている文章はおよそS2PLの事を指している事が多いです。 > Durability を一部諦めている（考えにくいですが） これは無さそうです。 TiDBの記事を読む限り「事前書き込み」が全部成功した場合に限り次のフェーズに進むそうですし、事前書き込みを永続化していないケースは無いのではないかと思います。S2PLはロックの解除前に永続化を済ませている事が条件なので「事前書き込み」が永続化されているならばこれは広義のS2PLと呼んで差し支えありません。 ここで問題になるのが何をもって「永続化」と呼ぶかという話で、直感的にはディスク書込の事を言うことがほとんどですが、もう少し考え方を拡張すると「システムが想定する範囲の障害があってもデータを失わない事」と言い換える事ができます。そもそもディスクに書き込んでもディスクごと吹き飛んだ（これはシステムが想定していない範囲の障害）ら意味がないですし、これまでは電源断からの復旧に耐えることをもって永続化と呼ぶケースが主でした。 Raftを用いた分散システムにおける「永続化」とはRaftが想定する範囲の障害つまり少数ノードの故障や離脱に耐える事であって必ずしもディスクに書き込むことを想定していない可能性もあります。TiDBはRaftで複製され永続性が保証されたストレージ(TiKV)の上に2PCなどのプロトコルを用いて複数データにまたがる一貫性を実現する構造になっていて、上下で役割を分担しています。そしてこの記事を読む限りは永続性に関してはTiKV側に任せていると取れるので実際の所S2PLに近いことが行われていると思われます。

熊崎 宏樹:技術面接の際にGo言語を選ぶ事はできますので、可能不可能という話だけで言うと可能です。 ただ「Go言語だけがめちゃくちゃ書けるけどC/C++やJavaはできない」という人間をこれまで一度も見たことがありません。もっと言うとコンピュータ・サイエンスの高い素養を持ち合わせながらC/C++もJavaもできないという人もお目にかかった事がありません。そもそも何か一つの事を突き詰めようとすると自ずとその周辺分野もある程度理解する必要があります、なぜなら理解しないと自分の分野にどの程度関わっているかすら切り分けられないからです。周辺分野に一度も興味を向けた事もなく高みに登ったつもりでいたらそれは視野が狭いだけです。Go言語もある程度以上の高みに至るとC言語と完全に無縁ではいられません。 Googleの採用の仕組みはCracking Coding Interviewにも書いてありますが、Hiring Committeeを通過した後に部署とのマッチングがあります。部署によってはJavaしか使わなかったりC++しか使わなかったりする所も珍しくないので、そういう所のマネージャは自然と「Javaが得意な人に来て欲しいな」ぐらいの事は考えます。そうしてマッチング先が一つも現れなかったら「今回はあなたに合うポストがありませんでした」として落ちる事は起こりえます。もちろん運良くGoを使っている部署とマッチングを果たすことも理論上はありうるでしょう。 これはGoogleに限らず言える事ですが、就活する際には「必要とあらば何でも学んでみせる」という覚悟を示すことは常に重要です。ですのでキャリアをGo言語と心中させにいくスタイルを貫くのはあまり賢明ではないと思います。 ここから先は完全に余談なのですが、GoogleはC++用のライブラリのabseilを公開しています。 https://github.com/abseil/abseil-cpp これは社内でC++を使い込むうちに常用されている部分を切り出してライブラリ化して公開されたものなのですが、例えばabsl::StatusOr<T>型は「成功時はT型の値、失敗時はエラー詳細を内部に持つ」という直和型でそれを返す関数をいくつも宣言して失敗時にはエラー詳細を早期リターンする、という感じのコードを absl::StatusOr<Foo> out = Bar(hoge); if (!out.ok()) { return out; } こんな風に延々と書いていると、Go言語で out, err := Bar(hoge) if err != nil { return err } と書いている時と書き味は大差ないです（個人の感想です）。Javaを使っても言語の文化としてCOBOLを書くことができるのと同様に、abseilを高度に使い込んだC++コードは文化としてGoを書いているように感じるときが度々あります。そもそもGo言語はGoogle社内でのシステム開発上での問題を解決するために作られた言語ですので、それらに類似点があるのは自然な話でもあります。 他の言語やライブラリも好き嫌いせず学ぶうちにGoの真髄に辿り着く事もあるかと思いますので是非幅広く勉強してみてください。

熊崎 宏樹:ARIESの本質、これは僕も疑問でした。Algorithms for Recovery and Isolation Exploiting Semanticsの頭文字を取ってのARIESですが何がSemanticsをExploitしているのかという点について考えるたびに別の答えが思いつくのでまるでわかりませんでした。 そこで去年、大阪に訪問していたC. Mohan先生（ARIESの著者）に直接聞いてみました。（Mohan先生の右後ろで目を閉じているのが僕です） 少し考えた後に彼は「ページのインクリメンタルな操作の中にすべての動作を畳み込んだ事こそがExploitである」と答えました。僕の理解はこうです。 * DBにおけるページとはただのディスクの断片ではなく、それぞれが独立したステートマシンである * 複数のステートマシンに対する操作（=ログ）に対してLSNという全順序関係を持った横串を刺してトランザクションレベルでの一貫性を設けた * ページごとにそのページに対して最後に操作を行ったログのLSNを記録し、それより小さいLSNのログはいついかなる時も無視する事で片方向の冪等な遷移しか起きない状況をロジカルロギング上でも達成した * リカバリ時においてはLSNの任意の断片の箇所に対して全トランザクションの成否が確定し、そこから続くインクリメンタルなRedoと更にそれに続くUndoの内容が確定する * UndoもCompensation Logを伴ったRedoというインクリメンタルな操作に畳み込んだのでAbort操作とリカバリUndoが共通化された データベースのロギングプロトコルの話を出発点にしてページをステートマシンに見立てる視座の高さに至るのは一種の悟りのようでありますが、ARIES自体はACIDにおけるAとDしか相手にしておらずトランザクションの並行制御についてはロックテーブル等に任せている事などを理解していくにつれてすんなりと理解できる事と思います。これが理解できたら発展形の一つであるInstant Recoveryについても調べてみてください。 ARIES/KVLとかARIES/IMはARIESで一貫性制御を行っている上でSerializableな分離レベルを実現するためのファントム避けのロックの話等をしているのですが個人的にはロックテーブルの側で対処すべきであってその辺の研究の流れはGoetz先生のOrthogonal Key-Value Lockingの研究の中でも説明されています。以下に引用します。 様々な試行錯誤を経た果てに地獄のように大きなロック互換表が出来上がっていますがこれはやむなしでしょうか…。以上参考になりましたら幸いです。

熊崎 宏樹:Pointer Swizzlingについて詳しくない人のために概要を説明しますと、これはメモリに乗り切らないデータの断片をメモリに乗せて処理している際に、データ内での参照関係を表す論理的なポインタをメモリ上でのみ物理的なポインタへと侵襲的に上書きする事で同じくメモリに断片的に乗っている宛先データへのショートカットを提供し高速化するテクニックです。上手くいっている時は速度面では申し分無いのですがディスクに書き戻す際に再び論理ポインタに書き戻す必要があるのと、ポインタを被参照されているすべてを書き戻さないと知らずに物理ポインタにアクセスしてSEGVという事故が起きうるのが難点です。 初期のPointer SwizzlingはMMUなしで仮想メモリっぽいものを実装したり、巨大データを扱うプログラミング中での活用を目的としており、RDBMSへの貢献というよりはOSやプログラミング言語に対するテクニックとして提案されていたようです。特にOSのレイヤーでサポートするならページフォールトをトラップしてメモリを侵襲的に書き換えるなんてかなり夢のようでかっこいい技術です。しかしOSという観点では仮想メモリでやったほうが筋が良いのと、ファイル側を書き換えることさえできてしまえばCPUに任意のメモリアドレスを読みにいかせる攻撃が可能という欠点があり、プログラミング言語でいうとUnswizzlingの管理のために言語レベルのガベージコレクションに頼ったりする必要があったりしてイマイチ広く使われるには至りませんでした。 そこでGoetz先生らが出した2014年に出したIn-memory performance for big dataの論文の中で * Swizzlingは簡単には使えないけどRDBMSのB+treeにおけるブランチノードのポインタに限ってだけ使うとかなり上手くハマるわ * でもB+treeの逆参照を管理する必要があるからただのB+treeじゃダメでFoster B-treeが良いと思う * 複数の逆参照をマルチスレッド対応まで考えて上手く回すのは難しいけどFoster B-treeは全ノードは常に一つしか親を持たないから安全 * 逆参照を上手く取り回すためには物理ポインタはページに直結じゃなくてページ固有メタデータに直結すると上手く行くわ という形で再導入されLeanStoreとかでも採用するに至った、という流れがあると認識しています。

熊崎 宏樹:良いですね。日曜大工でRDBMSを作るのはもっと市民権を獲得しうる趣味だと確信しています。 分散システムを作る際に気をつける事を語ると毎度長くなってしまうのですが、データ指向アプリケーションデザイン、通称イノシシ本に書いてある事をベースラインに説明すると明快であると気づきました。 * レプリケーションされるのはトランザクションログだけで良いです。それ以外の一切のものはトランザクションログから再構成できます * ユーザに完了を報告する際に必ず永続化されるべき情報と、ユーザから読み出しが起きた時に何らかの加工をすべき情報との間に線引きが必要です * 加工をいつどこでやるかは分散DB側の裁量に委ねられています。ログの複製と同時にページへのApplyを行うのがAurora式ですが、ログの永続化と報告だけ先に済ましてしまい、Applyに関しては適宜暇な時に流すのがSocratesとかAlloyDB、という違いがありますがどちらを選んだからといって大きな間違いは無いです。 * 通信プロトコルは枯れてるものならどれを使っても劇的な違いはありません。僕ならgRPCを選びます * 故障直前にメッセージを正しく送れる保証がないので、生き残っている側が定期的に生存報告を送る事で死活確認するしかありません。RaftのプロトコルはAppendLogのRPCの中に生存報告が含まれており無駄が少ないです * RaftであればLeaderからの生存報告が途絶えたと判定するまでのタイムアウト時間を各Candidatesが乱数で決定し、その時間が経過したらLeaderに立候補します。Leaderの生存報告待ちだった他のCandidatesは一番最初に観測した（充分最新の）立候補に投票するので、乱数で決定する事になります。Paxosベースだと実装の幅があるのですがRaftのこの乱数タイムアウト立候補方式の方が引き継ぎが速いという利点があります * インスタンス同士のメンバシップはLeaderがステートマシンの中で管理するべき情報の一部です。つまり参加や離脱に関してはLeaderが認識してそのメンバシップ状態をアプリの情報とは別のレイヤーで共有し続けます。ですのでLeaderと通信できる限りは漏れなく認識できています * CockroachDBの論文の中で報告されていた事によると、障害やノード追加によるメンバシップ変更に伴うリバランス時には障害への耐性が弱まってしまうのでJoint Consensusという方法でメンバシップ変更前後のそれぞれの状態に対するメッセージの通信を独立して行う事で解決したと言っています。曰くシンプルで堅牢なアルゴリズムとの事ですがちょっと説明は難しいです Raftの挙動については英語ですがこのアニメーションの図解が一番わかり易いと思っています。 https://thesecretlivesofdata.com/raft/ もっと質問がありましたらどんどん聞いてください。

熊崎 宏樹:levels.fyiの情報を見るに中央値での年収199kドル（1ドル151円で約3000万円）というのは日本企業の中では破格と言って良いと思います。Googleと比べても劣らないと言えますが同一の職グレードに至るための難度が各社で当然違うので人によってどちらでより高く評価される事もありえますし比較は難しいです。 https://www.levels.fyi/companies/woven-planet-group/salaries/software-engineer 友人との噂話を総合すると、環境や待遇は申し分ないがソフトウェアカンパニーとして色んな意味でやるべきことがいっぱいあって人を選ぶかも知れない、という印象があります。と言ってもこんな事を言うとどこの会社もだいたい多かれ少なかれその通りなんですけれど…。

熊崎 宏樹:負債を繰り上げ返済する事の意味が大きいのは金利が高い場合です。逆に言うと負債の金利が安いのであればお金ではないのでそのまま踏み倒しても構いません。 どうした場合に「金利が高い」と言えるでしょうか、それは利子の返済に苦しんでいる場合です。もっと言うとキャッシュフローが許容できない程マイナスになっているときです。逆に言うと同じエンジニアリソースを割いた時の利益の増加の方が負債の繰り上げ返済より利得が大きいと判断したのであれば追加で負債を増やしてでも利益を増やす事がフロー改善のために合理的なこともありえます。 そもそもお金でないものをお金に喩えてる所からやや掛け違いが起きていますが、負債というメタファーでエンジニアリング上の意思決定を振り回すのであれば「お金はできるだけ早く返さなきゃ」なんて安直な議論ではなく、ビジネスの拡大と金利のバランスの中での舵取りとして考える方が建設的であります。 その上で、ソフトウェア開発での負債に乗る金利というものを正しく評価できているでしょうか？リファクタリングで返済できるような小手先の問題でしょうか、それとも構造レベルでのデバッグを要する大きな欠陥でしょうか？まずはそのあたりの可視化とモニタリングから取り組むのが解消の第一歩だと考えています。

熊崎 宏樹:研究者であれば研究とその成果の共有（論文など）こそが本分であり、誰もが絶対に特許を出すべきだとまでは思いません。 特許のそもそもの目的は「事業上の優位性を保つために研究成果を秘匿したまま事業化されてしまうと発明が独占されて社会の損失になってしまうので、研究成果の公開とその先行者利益の保全を社会レベルで推し進めること」です。つまり事業や利益の話を抜きにして特許の話はできません。 ビジネスの戦略上、特許を取得して知見を公開しながら社会に先行者利益を認めさせる腹積もりならもちろん特許を出すべきですし、その過程でその研究内容について一番詳しい企業内の研究者にその特許を取得せよと業務命令が下る事は全く自然な成り行きです。その時に特許を出す労働者は研究者とはいえビジネスマンとしての色合いの方が濃くなると言えます。 大学の研究者ももちろん特許を取ることはありますが、特許はそこから展開するビジネスで得る利益を保護するための仕組みであって、その利益の計画が全く無いのに特許を取るのは特許の哲学に沿っているとは思いません。もちろん誰しもがこの資本主義の中で生きる限りはビジネスマンとしての顔を持ち合わせていて、あらゆる研究者が特許を取る事ももちろん肯定されるべきですが、特許を出しているその瞬間には「これでひと儲けするつもりです」というビジネスマンのタテマエで特許を出しているという意味では研究者と呼べないという主張も一理あると思います（僕はビジネスマン兼研究者というキャリアは大いに結構だという立場です）。 僕の専門であるソフトウェアに限って言うと、ソフトウェア特許を取るというのはあまり有効でないと感じています。まず自然法則を利用した技術的思想の創作としてソフトウェア上の発明を定義することが大変な上に、他人がそれを侵害している事を立証するのも一苦労ですし、裁判で争って特定の発明成果を取り合うよりもっと別のビジネスを探しに行くほうが利益の期待値が高いと考えているからです。裁判で争う価値のある特許が世の中に存在する事は肯定しますが、これから提出する特許にその価値がつく確率は高くありません。また特許はその先20年での権益を保護してくれますが目まぐるしく進化が加速し続けるソフトウェアの業界において今後20年と同じビジネスが保てると想定するほうが無理があります。 また、これから行う行動が後から他人に特許が取られてしまうかも…という懸念を口にする人も居ますが、心配であれば論文なりブログなりでどんどん発信してしまうと良いです。それなら他人に特許が取られても過去に発信した情報を元に公知であったと主張すればあちらの特許を無効化できるので自分の情報公開の1年6ヶ月以内に侵害する特許が公開されなければその後の特許はすべて無効にできます。サブマリン特許はもう塞がれてるのでまず心配する必要もありませんし…。 長くなりましたのでまとめると ・特許は取りたかったら取っても良いがビジネスマンとして取るタテマエが前提になる ・ソフトウェアに関してはビジネスマンが利益を追うなら特許以外の方が効果的だと思う 以上参考になりましたら幸いです。

熊崎 宏樹:ちょうど解説しているサイトがあります。 https://www.windytan.com/2012/11/the-sound-of-dialup-pictured.html 図を拡大すると結構たくさんの情報をやり取りしているようです。 * 「ピーピロピロ」で自己紹介して今後の通信に使える方式を情報交換して決定し * 「ロロ」でお互い送れる信号の周波数の高さで減衰などの聴き比べを行って上手く通信できそうな速度を決定し * 「ザーザー」でお互いにノイズを送りあってその状況で「１」という信号を送り合う事でイコライザを調整して受信信号を最適化する という感じのようです。電気のことは詳しくありませんがkm単位で遠い相手と通信する以上、その経路では様々なノイズや減衰などがありえるので接続の度に注意深く調整をしていたようです。 ダイヤルアップという名前の通り電話回線の上でこの通信を行っていたのですが、電話回線に流しているうるさい通信をそのままユーザーの耳に入れる必然性は全くありません。これに関して諸説あって、最初期のモデムは電話回線直結ではなく電話の受話器に向かってスピーカーとマイクを向けていたので通信中の音が聞こえるのが当たり前過ぎて逆に音を出さないというアイデアがなかったとか、単純に不具合が多かったので検証に便利だったとか、当時の電話網のユーザーはほぼ人間だったので間違えて人間のいる番号に掛けてしまった場合にはザーザー音の代わりに向こうの人の肉声が聞けたので発信側がすぐに間違いに気づけて便利だった、とか言われています。

熊崎 宏樹:端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリーフ以外の部分（ブランチノードやインターナルノードと呼びます）にキーに対するバリューを保存するかどうかです。そしてノード1つはバッファプールで管理される1ページを保持しています。ページサイズが同じならB-treeはブランチノードの中にキーに加えて値の実体も保存する必要があるのでブランチノード1つが保持できる子ポインタの数は自ずと少なくなります。対するB+treeはキーに対応する値を持たず子ノードのポインタだけを持てばいいのでブランチノードが保持できる子ポインタの数はB-treeより多くなります。下図参照↓ これによってB-treeは探索が木の途中で終わる可能性もある一方で木全体は個々のノードの小ポインタが少ないせいで高くなりがちでB+treeは木が低く抑えられます。データベースとしては検索対象のデータが常に全部バッファプールのメモリ内に収まらないという前提があるのでページのいくらかはディスクに置いたままにして、メモリの速度を最大限活かす必要があります。 さて下にB-treeとB+treeを模式しました。B+treeの方が子を多く持てるので3〜4の子ノードを持ちます。B-treeは子ノードを持てる数が少ないので2ページを子として持ちます。赤のページがメモリに載っているページで同時に5枚までしかメモリに載らないとします、黄色のページがディスクにしか無いページでその読み出しには多大なコスト(HDDの場合10ミリ秒、3GhzのCPUにとって3000万クロック！)がかかります。B+treeはブランチノードがおよそずっとメモリに載り続ける仮定ができます。B-treeはルート含めどのページにも目当ての値が保存されている可能性があります。 B+treeはどの値を読むときも常に確定で1回のディスクシークが必要ですが、メモリに乗り切らないデータを扱う以上は避けられないコストであります。B-treeは運が良ければメモリだけで値を返せる可能性もありますが最悪の場合はディスクシークが3回になります。しかも目的のページを運良くキャッシュできている可能性はディスクとメモリのサイズ比が広がる程に悪化していってしまいます。そのページに目当ての物があった場合のディスクシーク回数の回数を書き足すと以下のようになります。 B-treeは全部で15枚あるページに対して期待値1.53回(=23/15)のディスクシークでアクセスできます。B+treeは常に1回です。B+treeの方が少ないディスクシークと言えます。ハードディスクがとにかく遅い時代の設計なのでそれと比べるとツリーを辿ることのCPUコストは無視して論じる事が出来ます。 とここまでが古典的データベースの話ですが、最近は結構事情が違います。近年では * MySQLにアクセスするデータは99%以上バッファプール上のデータに当たるまでシャーディングなどでチューニングする事が良くある * メモリの価格が劇的に安くなったのでメモリに乗り切らないデータは扱わないと初めから割り切ったインメモリDBも台頭 * 何なら世の中のDBの9割は5GB未満しか保存していないなんて与太話もある * ディスクシークはNVMeでめちゃくちゃ速くなったのでデータベースアクセスの支配項が移った * 構造上ブランチとリーフに多重で同一のキーが保存されるB+treeはキーが長い文字列や複合キーなどによって複雑に長くなった場合に無駄が多い など、MySQLが設計された頃とはハードウェアや使い方の様子が大きく様変わりしているので今後またB+tree以外のデータ構造にも脚光が集まるシーンが来るのではないかと期待しています。

熊崎 宏樹:眼の前の仕事を上手くやる、という技芸レベルの話では実はそれほど他社との決定的な差はなく、組織として上手く行ってるのはとにかくスケールする事を意識しているのがポイントではないかと思っています。 組織構造のデバッグが上手 仮に全社員が優秀で与えられたタスクを誠実にこなしていても、組織を大きくしていくと部署間で細かい矛盾が起きたり正義が衝突することは珍しくありません。また衝突しなくても特定の問題を解決する部署が事実上存在しなかったり問題自体が放置される事は一般的な組織において珍しくありません。 Googleが組織として上手くやっているなと感じるのはそういった組織内での矛盾を早期に見つけて自発的に解決しようとし続けているという点です。技術の創造と設計という本から図を引用しますと このように組織内での分担は膨らんだり縮んだりするのが自然の流れですが、現状の自組織が何を見落としているかを積極的に見つけ、組織の再編によってデバッグする事でみんなが働きやすくなるようにしているようです。単に組織再編だけなら大抵の組織で行われている事ですが、それによって構造レベルのバグを取り除くという力強い意志を感じています。大量のサービスが時に惜しまれながら終了しているのはもしかしたらその片鱗かも知れません。 日本の会社については詳しくないので伝聞からの推測ですが、組織レベルでの目標を見失わずにメタなレベルでのデバッグを繰り返し行っている会社としてはリクルートがそれに近いのではないかと想像しています。 文化の洗練に多大なコストを支払っている また大企業において、間接的に数百人という部下を抱えるクラスの人の発言は本人不在のままでも部下の間で繰り返し再生産され伝言ゲームが行われ、出席していない会議においてすら影響を及ぼすものですがGoogleの偉い人は何万回再生産されても構わない正しい事を文字通り部下全員に向けて直接発信しています。よくニュースサイトで「スンダー・ピチャイCEOが全社員向けに伝えたことによると…」などといった文字列が出ますがこれは本当に文字通りヒラ社員隅々まで受け取ることになるメールで直接語りかけています。CEOレベルでなくてもVPなどのそれぞれも結構な頻度で部下全員に何を目指して行くべきかを伝言ゲームではなく直接的かつ具体的に伝え続けています。 Googleの偉い人が具体的に何をやっていたのか、というのを元VPレベルだった人がブログに公開していましたが、文化を維持して高めて行くのに弛まぬ努力が必要なので「まるで職場の花に水をやるように」忍耐強く繰り返し力を加え続けることが重要であったとの事でした。こうして一歩間違えば壊れたレコードとでも評されてしまうような複雑な事を適切にやり遂げるのは特定の年数働いて自動的に昇格しただけの人間には荷が重すぎます。文化を動かし発展させることができる人間をどのように見つけ出すのか僕には想像も付きませんがそれを上手くやれているのがGoogleを他にない会社にできている要素ではないかと想像しています。 超人が頑張れば3人分ぐらいの仕事ができるかも知れないにせよ、100人の部下の生産性を1割高められれば10人分の仕事が出来たと換算できるので、組織が大きくなるにつれ「自分以外のみんなの生産性が上がる」という事自体に掛けるべき比重が上がっていきます。それが組織をスケールさせるという言葉の意味であり、昇進するに伴い適切に難度の高い仕事を優秀な人に割り当てていく継続的な仕組みの良し悪しがゆくゆくは会社の命運を左右することになります。「Work Rules」とか「Googleのソフトウェアエンジニアリング」などの本には嘘は書いていないので書いてあることを真似れば確かにGoogleっぽい会社を作ることは可能かも知れませんが、それはあくまで会社のハードウェアの話であって、文化という究極のソフトウェアは書籍化しようが社長がトップダウンに推し進めようが一朝一夕では模倣出来ませんし、そこに真の組織的強さがあると感じています。 Googleは明らかに僕より賢い人が作り上げた仕組みなので僕の貧弱な知力では解釈して説明できるのはこれぐらいですが、何かの参考になれば幸いです。

熊崎 宏樹:天才プログラマと言われて頭に思い描く人物が複数いて、共通点が実はそんなに無いので共通点を洗い出すのはやめて「自分だったらできないだろうなぁ」という事例を思い出した順に列挙してみます。 しょぼそうな高速化がめちゃくちゃ刺さる 凡人に理解できないような天才的なアルゴリズムを用いてめちゃくちゃ計算量を減らしている、なんてことは実はほぼ見かけなくて実際によくあるのがこのパターンです。賢いアルゴリズムというだけなら素養のある秀才ならなんだかんだ思いつくので個人的には天才とまでは感じません。 天才は「Aを受け取って計算してBを返す」みたいな一見平凡な処理に対し「Aの配列を受け取って結果をBの配列にして返す」みたいな誰でも思いつくようなしょぼそうな効率化を行って途方もない効率化を果たします。もちろん凡人が任意の場所でそういう細かい最適化を入れて同様の効率化が再現されるわけではないのですが、天才はただのバッチ化やキャッシュ等で10倍速以上に高速化できる秘孔を適切に突いてきます。脳内にモデル化している計算機のエミュレーション精度が異様に高いのではないかと想像しています。 とにかく異常に手が速い 天才はノッてる時のコーディング速度が異常です。一日で1〜2万行ぐらいの異常なペースでそれなりに頑健なシステムを作ってきます。凡人は数百行書いてはバグり散らしてデバッグに数日溶かし…というサイクルを回していますが、天才は一晩でモジュールいくつかを書き上げて動く物を出してきます。そういう天才は似たような目的のコードをいくつも読んでパターン化して良い部分を適切に模倣できるので実装の作法に試行錯誤する時間が短いのではないかと想像しています。 斬新なインタフェースを備えている ソフトウェアとは抽象化の連続です。同じ抽象化をする限りはその裏で行える実装の幅には限界がありますが、内部の仕様からくる都合を上手に隠蔽した抽象化は速度面やコーナーケースで意外な恩恵を示す事があります。パッと見ただけでは何だか野暮ったくて使いにくいAPIだなぁと感じる事もありますが、深く内面を理解したり他の抽象化と比べていくともはや元のAPIには戻れないような中毒性を備えたインタフェースにロックインする事になります。天才は異世界からの転生者のように「こうやって抽象化するのが一番自然だろ？」と事も無げに言いますが、凡人からするとコロンブスの卵のようです。 無味乾燥なデジタルの世界において物事をどう捉えるかというのは想像以上に大きな影響を我々の思考に及ぼしており、どんなに新しい概念でも想像しやすいメタファーに寄せて考える事で一気にフォーカスしやすくなります（これは別の可能性を無意識に切り捨てる事と表裏一体です）。天才が描き出す抽象化は自然とチーム全体の基底ベクトルのような働きをしてくれます。