25章 サービスとしてのコンピュート
冒頭がリスコフの言葉ってあついな
25.1 コンピュート環境を手なずける
cgroupsとchroot監獄、ファイルシステム分離用のバインドマウントやユニオン/オーバーレイ
コンテナの仕組みについてすごく勉強になる
本書は訳注が充実してて良いですね
設定パラメータ自体が長期的には非効率の原因
パラメータのあるプロダクトは甘え。漢は黙ってZero Config的な主張って何処で見たんだっけ
A Philosophy of Software Designだった
UNIX哲学的でもある
簡単なことは簡単であるべきで、複雑なことは可能であるべきである
コンテナのサイズ調整は基本自動で、手動でも設定できるということのよう
未知のプログラムの使用リソースは実行してみないと分からないので、完全自動化はそもそも難しそう
ただ、大半のプログラムに対しては実績に基づいて統計的な予測が可能そうなのも確か
最初から複雑になることを予想して、複雑になったとしてもスケールするように設計しておくべきっていうのはいい話だな。自分も気を遣っているつもりでも忘れがちな気がする。
BigDesignとEnoughDesignの塩梅について知りたい。特にGoogleのような大きな企業のプロダクトだと新規プロダクトのミニマムスタートが難しく、大きく設計しないといけないような気がする。そんなことないのかなぁ。
20%ルールで作ったプロダクトがどうやってローンチまで漕ぎ着けるのか?
Googleのデザインは機能は少ないが自由度が高い。スケールを意識している?
自由度は低いが機能が多いとスケールしにくい
失敗しているプロダクトも多い
Googleは目的が明確な場合にたくさんの手段は許してくれるが、手段まで明確な場合(Appleが得意)、目的が特にない場合(SNSなど)は苦手?
手段まで明確な場合はGoogle発ではなく買収したものが多い: YouTube, Firebase, fitbit ... etc.
25.2 マネージドコンピュート用ソフトウェアを書く
Googleにおける正規のフレームワークはMapReduceであり、後にFlameに取って変わられた
分散処理周り(HiveとかKafkaも?)単語は聞いたことあるけど、これまで仕事として縁がなかったこともあり、知識が全然ないと感じる
ペットと家畜の例えがちょっとノンエシカルな感じがしてしまった><
特注品と量産品
25.3 長期的にスケールするCaaS
全てのこうした状態(ホスト名・タイムスタンプ・PIDの値の組で一意にプロセスを特定できる)の箇所を特定し修正する取り組みは、8年後の現在もまだ続いている
1章の頭に出てくるHyrumの法則の本当の恐ろしさが最後の章で言及されている
「無意識に依存している点を抽象化する技術が後から出てくる」ことを予測することは不可能なので、一生付き合い続けることになる
チーム開発での困難さとして真っ先に言及されて、戦い方が散々説かれてきてからのこのオチ
ながい!!!!やりつづけているのもすごい。
組織内の全ワークロード向けの共通コンピュートサービスにより、Googleはこの線形のスケーリング要因を避けることができる
クラウドコンピューティングのメリットとして10年くらい前にめちゃくちゃ聞いたやつ
これを業界全体でやろうとして成功させたAmazonの先見の明はすごい
とうとうガバメントクラウドにさくらインターネットが
Googleの場合、大半の時間はバッチジョブを事実上コストなしで実行していることがわかっている
自社でハードウェアを持って抽象化することのメリットがさらっと述べられている
DHHが脱パブリッククラウドして小規模にこれをやろうとしている
MRSKはKamalという名前になったようだ
Basecampのようなトラフィックが安定しているアプリはオンプレの方が安い。けどオンプレはつらいので社内クラウドにしよう
Google Cloudはこの形に近い
AWSはなんでもマネジメントサービスがある
Azureは複雑なところを抽象化する
25.4 コンピュートサービスを選択する
Borgのプールは提供ジョブとバッチジョブの双方を対象に含めており、どのデータセンターでも唯一のプールとなった
シンプルにしたいけど、ここまでできるモチベーションと技術力と教育力がすごいな。
ashに対しては「だが、断る!」っていいたいw
各種エコシステムに取り囲まれているし、コンピュートサービスの変更にともなって様々なものが書き直しが必須っていうのはよくわかるな。。。
抽象化の底だからどうしようもない
「25.4.2 抽象化のレベル:サーバーレス」のあたりが全体的に結構いいこといっているかんじがする。ビジネスモデルよく考えようぜっていうのほんとうにそうなんだよな。
アプリの十分な数のインスタンスをウォームアップしておくためにコンテスト開始数分前にコンテストのウェブページを呼び出して人工的なスパイクを起こす
これが必要になるのと似た理由で、サーバレスの登場でJVM言語が斜陽になってるという人も
Nodeまわりのパフォーマンスチューニング、慣れればいいのかもしれないけど、JVMでjfrとかvisual vmとかになれてしまうとなかなかつらい。ので、長期的にメンテナンスする可能性があるものはJVM中心につくりたくなってしまう自分がいる。。。(だがしかし、async/awaitまわりがJavaはネイティブになかったりするのでそのへんがなおらないとなんともつらい
クラウド事業者を選ぶ際の目立つ懸念点は、ロックインの恐れがあること
為替リスク馬鹿にならないですよね。AWS/GCP/Azureのどこを選んでも米ドルにロックインされる
それでガバメントクラウドにさくらが選定されたりしたんだろうか
25.5 結論
アプリケーションが簡単かつ自動的に取り替えられるノード群から成るように設計
かすっているくらいの文脈ですが、Apache BigTopまわりを紹介しているSlideshareをみていたんですが、そこでもノードを簡単に切り替えられるように設計しておくことで、性能アップはマシンを足すだけっていう単純化ができるってあって、こういうのがシステムとビジネスにおけるDDDの重要性みたいなところだよなーってあらためて思うなどした。
25.6 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
どんな組織でも、Googleがたどった道をたどって自前のコンピュートアーキテクチャを一から開発することはありそうにない
とうとう本文で言い切る章が出てしまった
だけど、これはまさにそうなんですよねw
もうすこしいえば、自社でk8sなどをふくめた社内プラットフォームってどうするんだっけ?っていうのは大きい事業を抱えていると本当はすごい金額になるからかなり同じようなことを考えることにはなりそう。
Borgをつくるみたいなことはないだろうけど、k8s上にもっとPaaSっぽく扱えるための基盤をさらに被せるのかとかいろいろあるんだろうなみたいな。
知り合いがAppleのプライベートクラウドに関わる部署にいるので、Appleがどの程度のCaaSを開発者に提供してるか聞けるかも
現場でどこまでできているか?
よく見かけるのが、プラットフォームチームが提供しているものと、もっと素のクラウドみたいなものとがあったりするんだけど、プラットフォームチームが開発チームの要求をうまく取り込んで、全体的にコストが抑えられているのって実はあんまりみないかも。。。?実はできているんだけど、正確に数値化していないだけかもしれない?
抽象化の置きどころが難しい。「コンピューティングリソース」というのは良い落としどころかも
他にもDesktop as a serviceも似ている
この本があるのになぜ実践する企業はすくないのか?
アメリカやオーストラリアでプラットフォームエンジニアリングが前に出るようになったり日本でもTeam Topologyがどんどん前に出ていてこういうアーキテクチャをゼロからつくるわけじゃなくても、自分たちのビジネスにあったシステム基盤を作るっていうのはよくある話だと思うんだけど、ビジネスがそこそこ利益率よくて長年続かないと、そういうのをうまくやり続けるための体力がなくて、最初に決めたものでそのまま継続してしまうみたいなのはよくあるかも?
ソフトウェアにお金をかけてレバレッジ効かせるようなビジネスが飽和している可能性がある?
なにをよりどころにシステムを設計するのかっていうのが意外と曖昧だったりする?(クラウドベンダーのリファレンスアーキテクチャや資格に出てくるパターンやアーキテクトに相談する方が賢い可能性を捨てているとか?)
スタートアップでまず必要なのってバックエンドのアプリを書ける人で、本文に書かれているような「計算リソースの抽象化に合わせたアプローチ」まで考慮して実装ができる人って本当に限られている気がします
今後、サーバレス向けの使いやすいフレームワークがメジャーになれば初手をそれで構築するスタートアップも増える気がするけど、サーバレスはサーバレスであるゆえにクラウドベンダーにロックインされてしまうので、オープンソースで出てくる可能性は低く望み薄
Lightsail 的なアプローチのパッケージをサーバレスで提供するサービスが増えれば初手をサーバレスで構築するのがもう少しメジャーになるかも
メジャーにならないうちは人材も育たないから初手で選ばれることはやっぱり少ない、という循環からサーバレスはまだ抜けられていない
それの乗り越え方はなにか?
事業責任者と何を捨てるシステム設計(とある要件に対応しようとすると作り直しになってしまう設計)について、パフォーマンス、UX、ユースケースの観点で整理しておくとか?
ステップを小さくするとしたらどうできそうか?
プロダクトロードマップのパターン出しとそれに対応する開発と運用の予算パターンとアーキテクチャ案とかを整理するとか?
それが長く続けばプラットフォームチームができるんだろうし。。。とか。
アプリの運用が枯れてきた場合に、インフラ面でコスト最適化を行う
スケール性とパブリッククラウドのコスト、人件費を考慮して、どこまでインフラの運用を自社で持つか
完全サーバレス化もあれば、Basecampのようにオンプレ回帰もありうる
今のようにプライベートクラウドを構築するエコシステムが発達したからオンプレ回帰の話が出始めた
t_wadaさんの螺旋の話
さくらがk8sを構築できるサービスを公開したら使う人は増えそう
ロックインのリスクが小さい、為替リスクはない、サポートは日本語