熊崎 宏樹:例えば「じゃがいもと人参を受け取ってカレーを作って返す関数」というものを例にお話します。 その関数はコードで書くとこんな感じになりますよね。 typedef struct { ... // じゃがいも構造体の中身 } Potato; typedef struct { ... // 人参構造体の中身 } Carrot; Curry CookCurry(Potato p, Carrot c) {...} Cではこの関数は実は問題がある可能性があります、なぜならCでの関数は「値渡し」しかできないからです。つまりこの関数を呼び出すときには、内部的にはこの関数のためだけにPotato構造体とCarrot構造体を複製して渡す事になります。複製にかかるコストは構造体の大きさに比例しますから潜在的にものすごい量のコピーが起きる可能性があります。 ところでJavaではオブジェクトは関数に対して参照渡しされるので、構造体のコピーが起きる事はありません。関数に対して「人参は冷蔵庫の野菜室にあるもの、じゃがいもは足元の箱に入ってるものを使ってね」のように材料の実体ではなく、材料の場所の情報そのものを渡すので材料の複製を行う必要がなくなります。ただしこれは良い事ばかりではなく「シチューに使うつもりで冷蔵庫に入れておいた人参なのに無くなってる！」みたいな行き違いが起きる事もありえます。ですのでImmutableパターンという物で「見るだけにしか使わないなら参照経由、実際に書き換えを行うときには複製する」みたいに迂回することもあります。これが値渡しと参照渡しの違いです。 ところでCでは値渡ししかできないのですが「場所の情報」を表現する方法があって、それをポインタと言います。 Curry CookCurry(Potato* p, Carrot* c) {...} こんな感じで「じゃがいもの在り処と人参の在り処」を渡す関数として定義すれば、その在り処が書かれたメモ自体は値として複製され渡されますが、実体としては参照渡しと同じことが行われます。参照で渡すのですからそこでの注意点はJavaと同様です。

熊崎 宏樹:僕の意見は「役に立たないとは思うが、殊更に役に立たないと主張する人のほうが役に立たない」です。 競技プログラミングと業務の関係は例えるなら100メートル走とサッカーのようなもので、どちらかに優劣があるわけでもなく、どちらかのトップアスリートがもう片方でも必ずしもトップアスリートとは限りません。 サッカーの試合中に瞬発的に短距離走の速度が重要となるシーンもありますが、サッカーの試合結果は足の速さのみでは決まりません。業務でも時々競技的なコードを書く必要に迫られることもありますが、もちろんそれのみでは業務は終わりません。その割合に関しては現場に依存するので一概なことは言えません。 ここで重要なのは「100メートル走がちゃんとできる人間はサッカーも人並みにできる」という事です。100メートル走で一人の競技者としてやっていくには靴をちゃんと履いて左右の足を交互に動かして地面を蹴って狙った方向に前進する必要があります。サッカー選手でこれが必要でないと言う人は一人もいないはずです。競技プログラミングでトッププレーヤーになる必要はありませんが、人並みにやっていくために身につける基本動作は業務でも共通します。 言い換えると「競技プログラミングは業務で役に立たない」と得意げに言っている人で、競技プログラミングの基本動作ができていない人は、まるで自分の足で走れないのに「100メートル走はサッカーの役に立たない」と言っているようなもので両方やっている人からすると滑稽に見えます。 まずは靴紐を結んで自分の足で自在に移動できるようになる事が試合で役立つには必要で、競技プログラミングのために舗装された様々な学びの高速道路はそれを獲得するためにかなりコスパの良い道であると考えています。100メートル10秒を切るまでやり込まなくていいので怪我なくタイム計測ができる程度までやる価値は大いにあります。 競技プログラミングはコードを書く競技ではありますが、書いたコードがいきなり正解である事はほとんどなく、どこでバグが混入したかを素早く見つけて解決する必要があります。これはコード規模に違いこそあれ業務でも重要なスキルであり決してバカにできるものではありません。僕もレッドコーダーと一緒に仕事をしたこともあり、彼は途方もなく巨大かつデバッグ困難なコードベースを相手にしていましたが、その場でも筋道を立てて問題を解決に向かわせる力は確かなものだと感じました。

熊崎 宏樹:基礎を学びましょう。 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にとって代わられない仕事ができる」です。

熊崎 宏樹:そもそもインターンが目標というのが少し立ち止まって考えて欲しい所です。ここで僕の好きな記事を一つ紹介します。Joel on Softwareという有名なブログの「Finding Great Developers」です。英文に抵抗があるならページごと機械翻訳に投げ込んでも構いませんが、僕の文脈でピックアップして伝えたい部分だけ掻い摘んで伝えます、僕によるバイアスを含むので興味を持ったら是非原文も読んでください。面白くておすすめです。 * 世の中には「優秀」「無能」の2種類の人材がいて転職市場に出回っている人材のほとんどは後者 * 何故なら前者は重用されて出回らないからその人の生涯で4度程度しか転職市場に現れない * 転職市場は期待できない人間ばかりだが、優秀な人材は学生の中には社会と同程度には居るはずなので学生の中で探すほうが優秀な人材と巡り会える期待値が高い。それを市場に出てくる前に捕まえるのがインターン * ソフトウェアの世界での優秀さはその気になれば学生のうちの数年でも育つが、全く育てていない人が多すぎるので仕事の中での成長よりも才能で採る方が良い * つまり青田買いと相性が良い * インターンの中で真剣な仕事を与えて働きぶりをみれば面接よりも高い解像度で採るべき人材かどうか見極められる * 優秀であると確信した後でなら新卒より高い待遇でオファーをしても割にあう * なぜならそもそも新卒の普通の給料は人材が無能だった場合の保険を乗せて額面が削られているから これは米国の話ですが大筋では日本の労働市場でも通用します。インターンとは慈善事業でも子供向け人気集めイベントでもなく、企業がより優秀な人材を高い打率で掘り当てるための真面目な採用サイクルの一部です。「経験者を求めているインターン」というのは錯覚で、学生の中で有望そうな人をスクリーニングした結果、複数社の結論がたまたま一致したに過ぎないのではないかと思います。 さて「インターン獲得」という観点の話ですが、新卒市場に出回るような学生の履歴書は基本的には学歴+α程度しか載っていないものですから、それを見た時に人事部の社員が「この学生は高い解像度で比較してみても良いかも知れない」と思えるような学生という観点で考えるとそんなに難しい話ではありません。 * 関連の深い学科で高いGPAを獲得する * 努力で超えられない才能を持っている事をアピールする * 独学で調べて何かを作って発表していると良い、自主的に何かクールなことをやっている人間はコンピュータの才能があるかも知れない * 「やる気だけは誰にも負けません」という口先だけなら誰でも言えるのでやる気を客観的に証明できる経歴を残す * そう言えば昔こんな記事を書きました https://qiita.com/kumagi/items/62ec259ea86bdac1db4c * ただしこの指標はハックしようとするほどボロが出た時に痛いのでやる気が無いなら無理にやらないこと。ボロが出た話を風のうわさに聞いて書いたのがこの記事です。 https://kumagi.hatenablog.com/entry/career-hack * ブログやSNSや学会でポジティブな方向に目立つ * その会社が使用している技術の名前で検索した時に上位に出てくると理想的 * 採用担当だって候補者のフルネームやアカウント名で検索ぐらいします 注意点として、入賞歴やその他の華々しい活動は基本的にポジティブに受け取られますが「インターン経験」は学生の直感に反して警戒されます。3日程度の職業体験的なインターンならともかく、まともなインターンシップであれば優秀であると判明した学生はその会社の採用パイプラインに乗せて外に出なくなるようガッチリとホールドされて表に出てこなくなるはずです。それなのに表に出てきていて長期インターンの経歴が複数並んでいる履歴書は、それらの会社の採用パイプラインに乗り損ねた可能性があります。学生観点で見ると有名企業でのインターン歴が並んでいると勲章やトロフィーが並んだ履歴書のように見えるかも知れませんが、採用担当の観点で見ると多ければ多いほど良いと一概に言えるものではありません。ですので僕からできる確実なアドバイスは「学業を頑張りながら目立て」です。 日本の労働市場における「新卒カード」は充分強くてインターンに行かなかった位で絶望するような物ではないので、いっそ夏季休暇を全部趣味の開発に叩き込む方がキャリアに有利に働くかも知れません。 読み返すとありきたりな事しか言って無くてあまり役に立った気がしないので、有志が随時アップデートし続けている「インターン情報が集まる魔法のスプレッドシート」を共有します。既にご存知かも知れませんが。 https://magic-spreadsheets.github.io/

熊崎 宏樹:キャリアのために今から学位を獲得すべきか？という質問ですね。短い答えは「ノー」です。なぜならビッグテックは学位を採用条件にしていません。実際の求人をいくつか見てみましょう。ソフトウェアエンジニアリングの求人を適当にピックアップしたのであなたがこの文章を読む頃にも同一の求人がアクティブかはわかりませんが、傾向は変わらないはずです。 ビッグテックの求人例 まずは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 友人との噂話を総合すると、環境や待遇は申し分ないがソフトウェアカンパニーとして色んな意味でやるべきことがいっぱいあって人を選ぶかも知れない、という印象があります。と言ってもこんな事を言うとどこの会社もだいたい多かれ少なかれその通りなんですけれど…。

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