AI駆動開発で膨らむCI費用
こんにちは、AI駆動開発部の日常へようこそ。 このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの阿部が、 AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあよろしくお願いします。
よろしくお願いします。
はい、じゃあ、えっと、今回も阿部ちゃんの方から話題を提供してくれるということで。
今日のお題は何でしょうか?
AI時代のCI削減ですかね。
はい。
CI、コストの削減。
コストの削減ですかね。
はいはいはい。了解です。
多分、AI駆動開発をしていて、GitHubとか使っていて、テストをGitHub Actionsとかで回していたりとか、そのCIっていって、静的解析とか。
あとはAIのレビューを回している人とかは、特に参考になるんじゃないかなとは思っております。
そもそもCIって何みたいなところがあると思うんですけど、あとはGitHub Actionsって何みたいな話があるんですけど。
僕たちは基本的に手元のパソコンで開発をしているときに、手元でソースコードをAIが今は書いてくれて、
それの動作検証だったり、テストっていうのも実行してくれたりするんですけども、
実際にそれをチームメンバーに共有したりであったり、あとは本番にリリースをかけるにあたっては、
そのコードの品質っていうのを保証していかなきゃいけないよねっていう文脈から、
GitHubにその手元のソースコードを共有するGitHubにあげて、そのGitHub上でテストだったりデプロイっていうのを、
完全に僕たちのパソコンから独立した環境上で回すことで、僕たちの手元の環境に依存しない状態で安全にテストを回して、
リリースまで持っていけるっていう仕組みがもともとGitHubにはあって、
それを回す仕組みとかを、いわゆるCIとかCDとかっていうふうに、
継続的インテグレーションみたいな文脈でよく言われているような仕組みがあって、
普段開発をしているとこういうのを使っているんですけど、
僕たちはAIで開発するようになってから、とにかくAIの開発速度が速いっていうところもあって、
とにかく1日にGitHubにあげることができるソースコード量であったり、
あげるタイミングっていうのが以前よりも何倍も増えているところから、
GitHub Actions上でCI、テストを回す時間が拡増したっていうのが、
直近の1年半年ぐらいであるっていう状況です。
実際に先月かな、8月末かな、時点のGitHub Actions上の課金額とかでいうと、
僕たちは確か300ドルぐらいだったのかな。
日本円にすると5万円分ぐらいになっていて、
かなりコストとして肥大化していっているっていうような状態です。
これがだいたい6万分とか7万分ぐらい回ってその価格だったんですけど、
実は僕たち9月後半から10月の頭ぐらいの1ヶ月間ぐらいで、
その6万分ぐらいだった実行時間が今14万分ぐらいまで伸びているということで、
AI駆動開発が僕たちが伸びる、
AI駆動を前提に改善を進めれば進めるほど開発速度が上がっていって、
どんどんどんどんコストがかさむみたいな、
ちょっとそういう状況になっていますっていう感じで。
世界的にもそうみたいな、ちょうど一昨日ぐらいにGitHubが、
最近AIによって開発速度が上がりすぎて、
GitHubのインフラ自体がもう耐えきれないよみたいな。
インフラを再構築しますみたいな記事を出してて。
それを見ていたら、
例えば去年プッシュの数が6億件、7億件ぐらいだったのが月間で、
月間7億件だったのが33億件とかにまで膨れ上がっていて、
5倍くらい増えているというような感じで、
僕たちだけじゃなくて、
結構世界中でもGitHubのアクションズの実行時間が長くなっていて、
コスト肥大しているみたいな。
Xとか長別でもよく聞いたりするんですけども、
こんな感じでコストに悩んでいる人たちも多いのかなとは思ってますよね。
すごいね。
一応CIとかGitHubアクションズの回していることみたいなのを、
多分補足で言ってもいいのかなって思ってて、
プルリクエストを作った時とかに回るというのが基本的な仕組み。
あと、デベロップブランチとかにマージするタイミングで回るという前提があるんですけど、
基本的にはプルリクエストを作った時に、
E2Eテストとかユニットテストとかいろんなものが回るようになっているんですけど、
それ以外にも、例えばユーザーマニュアルを更新する、
そのサブを見てユーザーマニュアルを更新するみたいなことであったりとか、
あとウィキとか、エージェントMDとか、
AI向けのドキュメントとか諸々、
結局ドキュメントの更新ができなくて陳腐化していくみたいなところを、
わざわざAIに毎回ドキュメント更新してくれよっていうのがめんどくさいから、
そういうPRを作ったタイミングで更新していくみたいな感じで、
ある意味、本番リリースするまでの開発パイプラインの中に
組み込むことができるっていうのが結構いいというか、
嬉しいことみたいな感じになるかなと思っていて、
例えばこれがコストを無人像にかけていいのであれば、
もうテストとか手元で一切しませんと。
基本的にAIとかにE2Eのテストとかももう一切やってもらえませんっていう前提で、
CIが落ちたら、そのCIの中でクロードをまた立ち上げてみたいなことも、
もしかしたらできるかもしれないとか、
多分そういう、ある意味、開発の間で絶対に通るポイントみたいなのは、
それはプッシュするタイミングで、フックでみたいなのもあると思うし、
それの一つの例としてGitHub、Actions、CIは欠かせないみたいな感じになる。
多分経営者の方とか、コードとかまだ知識はないんだけど聞いておきたいみたいな人向けには、
そういう利点もあって、これは使いたいみたいなのが一個あるという感じですよね。
コーディング量が増えたのはまさに、僕とかだと一切コードを書いてないみたいなところから、
ちょうどさっき、3ヶ月半で1万600コミット。
すごいよね、これ。
僕が3年4年前ぐらいに、本当に完全に人の手でコードを書いてた時代って、
年間マックスでだいたい6000コミットとかだったんですよ。
個人単位よね、個人単位。
そうそう、個人単位で、しかも年間で。
しかもこの6000コミットってGitHub、結構いろんな人のリポジトリ眺めてると、
どっちかっていうとかなり開発してる人、すごいガッツリ開発ばっかりしてる人ぐらいの。
しかも開発してる人の中でも、より多い部類に入るぐらいの開発量だとは思うんですよ。
それがね、3ヶ月で1万だっけ?
そう、3ヶ月半で1万600コミットって言ってた。
しかも僕一人でね。
そうだよね。
AIによって、僕の前世紀の1年間の6000コミットから何倍にも膨れ上がってるような状態に出るってことですよね。
あとね、CIの時間、GitHub Actionsで開発の量が増えたっていうところもそうなんですけど、
僕たちはAIにレビューとかさせて、自分たちではプロリクエストのレビューはほぼしないっていうような。
動作確認をベースにね。
AIのレビューだったり、あとはテストを厚くするとか、E2Eをするとかっていうのでカバーするようになったことによって、
だから一個あるのが、AIからのレビューからのサイクル、レビュー機器のプッシュしてまたCIが回って、
またAIがレビューしてきて、っていうのがそのサイクルも結構増えたなっていうところもあって、
より積み重なるような状態になっているかなと思っています。
確かに確かに。
だからそれが、うちとかみたいな会社でもそうなってるってことは、世界中でそういうことが起きてるはずだという風に思うと、
GitHubは儲けてそうですよね。
めちゃくちゃ儲かってるけど、相当インフラきつくなってると思いますけどね。
ここ数年で、それこそ究極かもしれないですけども、100倍、1000倍ぐらいまでインフラの負荷が増えてると言っても過言じゃないぐらいなんじゃないかなと思いますけど。
だって阿部ちゃんがさ、エンジニアとして今まで年間6000コミットだったんだけど、3ヶ月半で16000コミットになりましたみたいな話してたんだけど、
一切今までコードを書いてなかった山本が18000コミットを3ヶ月半でやってるっていう状況だから、
倍とかそういう話じゃなくなっちゃってる。
全くない。
生産性とかじゃなくて、なかった動きが。
それこそ、タレントさんが自分でゲーム開発してるみたいなとか、そういうのも出てきたりとかしていてみたいな。
そういうことを考えると、すごいことになっていくよね。
今回はそれをとにかく高すぎるし、このままAI駆動開発進めてたらすごいお金がかかって仕方ないし、
何だったらそのダブルアクションズにかけてるお金をどうにかAIエージェント代に使いたいやんねっていうところで、
今日改善したというか、コスト削減した方法みたいなのを阿部ちゃんがシェアしてくれるっていう感じですかね。
セルフホステッドランナー導入の再挑戦
削減するって言っても、いくつかやり方あるかなって思ってて。
例えばそもそもCIを検査する量を減らすっていう方法があるかなと思います。
それっていうのは例えば、今だとコードを上げるときに、ギター部に上げてテストを回すときに、
全部のテストを回すっていうのを1回1回やってるとすごい時間かかるよねっていうので、
例えばコードの差分をチェックして、その差分の該当する部分だけテストを回そうとかっていうやり方があったりとか、
テスト側の改善をするって方向はあったりすると思うんですけども、今回僕がやったのはどっちかっていうと、
GitHub Optionsで、要はGitHubのプラットフォーム上でテストを回すとそこの時間課金がかかるから、
別の場所でテストとかを回しましょうっていうのをやったっていう話になってます。
その別の場所で回す仕組みっていうのが、実はGitHub上が優しくて用意してくれてるんですよね。
GitHubにソースコードを上げてプッシュするとかプレリクエストを作成するタイミングで、
セルフホステッドランナーと呼ばれるんですけど、それを起動するような設定を事前にしておくと、
そのセルフホステッドランナー、これは自分でパソコンだったりクラウド環境を用意して、
そこに指定をすれば、そっち側で回してくれるっていう仕組みになってます。
この設定自体は本当にパソコン、コンピュータリソースさえ用意できていて、
Linuxの知識さえあれば、ボタン何回か、4、5回クリックするだけで環境構築できるように、
GitHub側がいろんな準備をしてくれてるっていうので、かなり手軽に始められる仕組みなんですけど、
実は僕たち6月ぐらいにこの仕組みの導入を1回やって、実はあえなく失敗し撤退していたみたいなのがあったんですよね。
この時は僕たちは手元にあったMac mini、M1のメモリも16GBとかのMac miniを使って構築したんですけど、
結構GitHub Actionsが担っていた仕事が意外とありがたかったなっていうところで、
GitHub Actionsって1回の実行の度に全く独立の環境を作ってくれて、それを実行してくれてたんですよ。
なので、GitHub CIが回るときって数台のパソコンが起動して、それぞれ独立環境でGitHubActions上では動いてくれるんですけど、
僕たちが当時用意したパソコンっていうのはパソコン1台なので独立です。
1個の環境の中に複数のジョブが同時に走るみたいになったことによって、いろんなバッティングが生まれるようになってしまったんですよね。
データが残り続けるとかもね。
まさにそうで、例えばデータベースも同じ1個のデータベースを共有してテストを実行しようとしたりして、
データが整合を取れなくて落ちてしまうとか、それこそデータベースにどんどんデータが溜まり続けてストレージ逼迫して落ちてしまうとか、
あとはAIの認証情報とかもうまく渡す仕組みを作れてなくて、
当時はセルフホステットランナーを導入して、実行時間は一時期は下がったんですけど、ある時からテストが失敗ばっかりするみたいな状態になって、
ちょっと開発回らないよねっていうような感じで、会えなく撤退して、1回はGitHub Actionsにまた戻っていたのかな。
で、今回はもう1回リトライしたみたいな感じになってます。
Nixで環境をコード管理する
今回どういうことをしたかって言いますと、まずNixをやっぱりフル活用しようというような話になって、
Nixっていう仕組みを使ってコンピューターの状態管理を、しかも独立した状態管理をできるようにするっていうような仕組みを作りました。
Nixって何?みたいな話があったりすると思うんですけど、
Nixっていうのは、いろんなMacとかLinuxみたいな環境のOSごとに、
どういうふうにコンピューターのシステムの設定をするかっていうのを全部コードで宣言的に定義することができて、
これすごいのが、パソコンの細かい設定、要はMacの設定を開くと出てくるような設定項目を、
1個1個コードベースでパラメーター割り当てることで設定することができるし、
1個のコンピューターの中に複数のOSを立てて、それぞれ独立した環境を作ることができるし、
それぞれの中で使うためのツール、例えばGitHubと接続するんだったら、
GHCLIとか、要はAIを動かすんだったらオープンコードCLIとかいろんなツールを入れたりすると思うんですけど、
そういうのも全部1個1個独立して定義して状態管理できるような仕組みがあるので、
今回これも活用したっていう感じになってます。
これを使ってまずセルフホストするための、
GitHub上に接続するためのスロットっていって、
ランナーっていって、GitHub Actionsでセルフホストランナーするときに、
ランナーっていう概念があって、
どのジョブをどのランナーで実行するかっていうのを1個1個登録する必要があったりするんですよね。
このセルフホストランナーを動かすにあたって、
ランナーの設定とかもNixで宣言的に書くようにしていて、
実はこのNixの仕組み自体は昔からあって、
僕も自分で自分のパソコンの管理に1回Nixを使ってみようかなっていうのをやったりしようとしたんですけど、
これが設定が結構めんどくさくて、やっぱりコードでパソコンの設定を全部書かなきゃいけないのでやりにくいと。
ただ今AIがNixについてすべて知ってて、こういう風な構成にしたいんだよねって言ってあげれば、
Nixの構成勝手に作ってくれてやってくれるようになってるので、
今回の設定は全部AIにお任せしてやらせるようにしました。
これをやったことによって、パソコン、Mac miniを用意して、
僕のMacBookから、最初はMac miniを手元で初期化して、
初期化さえ終わったら、あとはMac miniに接続するSSHの接続環境を用意したら、
あとはボタン1個でNixを導入して、パソコンのセットアップを完全にしてくれるみたいな環境を作ることで、
かなりセルフホストの環境を作る手間がぐっと下がったっていう感じのことをやっていました。
これを今回やったことによって、ランナーを自由に設定して、
実行数が増えればランナーをどんどん増やすことができるみたいな、
まずそのコンピューターを管理するみたいな基盤を用意することができたような感じになっています。
CI費用を月60〜80ドルへ削減
実際に今動かしてみていて、
大体12個のランナーが実際にMac miniで走っていて、
結果として今直近1ヶ月の概算だと、
14万分分ぐらいのGitHub Actionsの実行時間になるところだったんですけど、
それの8万分分はセルフホストランナーで動いて、
残り6万分がGitHubで動いているっていうような感じになっている状況なんですよね。
この6万分が課金対象になるような状態なんですけど、
実はGitHub Actionsってエンタープライズプランに入っていると、
5万分までは実行時間無料になるので、
実質コストとして今発生するのが1万分になった。
14万分分かかる実行時間が1万分の課金のみで一旦は着地するようになったので、
お金に換算すると1万分というのは60ドルから80ドルぐらいになるかなという形で推移しそうなところまではようやく落ち着いた。
もともと300ドルぐらいからスタートして、さらに利用量増大したけど、
最終的には60から80ドルぐらいで月間推移しそうかなという状態に落ち着いた感じですね。
あとエンタープライズプランに移行したことによって、
定額課金はちょっと増えたけどみたいな感じ。
これも僕この対応する前まで全然分からなかったんだけど、
そもそも僕たちってGitHubのチームプランっていって、
1人当たり月4ドルのプランに入ってたんだけど、
それだとアクションズの無料枠が3000分だけだったんだよね。
それを月間1人当たり21ドルのエンタープライズプランに入ることで、
5万分分使えるっていう感じで、
これチームメンバーが多いとエンタープライズの月間コストが算じゃうのでやりにくいかなと思うんですけど、
僕たちはチームメンバー、GitHubに登録しているメンバーだけで言うと4人だったんで、
もともと4×4の16ドルだったのが4×21の81ドル。
81ドルの課金、差額で言うとだいたい70ドル分ぐらい追加するだけで、
CIの時間としては5万分、4万7千分分ぐらい追加でもらえるので、
エンタープライズに行った方がいいよって判断で、
エンプラを契約したような感じですよね。
これエンプラにすると戻れないよね。だからそれも注意が必要な時。
戻れなくはないっていうところがあって、
エンプラにしてプラスエンタープライズだけでしか使えないような設定をいくつか入れてしまうと戻れなくなるっていう経路があるので、
そこはもし検討するチームがあったときには、
AIに相談してあげると、この設定はオンにしない方がいいですねみたいなアドバイスをしてくれるはずです。
そういうことね。
もしエンタープライズから元のチーム利用とかに戻りたい、チームプラに戻りたい場合は、
エンタープライズから1回フリープラに移動して、
フリープラからチームプラにアップグレードするっていう経路をたどる必要があるみたいな。
それもちょっとだるそうやね。
ちょっとだるいね、だいぶ。
一応それをすることによって、
例えばプライベートリポジトリになったものがいきなりパブリックになるかっていう、
そういう重大な問題はないんだけど、
ステップが挟むことによってちょっとCIが止まっちゃうねとか、
そういうめんどくさい移行作業っていうのが生まれるぐらいかなと。
なるほど。
エンタープライズのプランで、
CI、ちょっと思ったんやけど、
そういえば聞きたいなってパターンを聞きたいなっていうか、
俺自身も調べたいなって思ってたんやけど、
例えばコパイロットがちょっと使える量が増えるとか、
そういうのってあんのかな、得点みたいな。
それで言うとね、ストレージとか、
AIの量は増えるけど、
AIは全く別枠だったような気がするんだよね。
なるほど。
あんまりCI分が増えて嬉しいなぐらいで、
もともとコパイロットも別にチームプランで無料で使える枠があるわけでもないはずだったから、
枠なのかなという理解だった。
あとセキュリティとコンプライアンスみたいなのか、
ヘッドハブアドバンスセキュリティで利用可能とかって書いてるね。
そうだね、あとはシングルサインオンが有効化できるよねとか、
そういうものがあったりするかな。
要は監査とか、あとは案理の統治をしやすいとか、
エンタープライズプランなので、そっち側の追加が多いかなと思います。
ランナーの並列実行と負荷分散
セルフホステッドランナーに移行する、コスト的にみたいなのもそうですが、
早くなったよね、マクリンとして。
早くはなったかもね。
計測レベルで言うと、
同時実行の数に結構影響を受けやすくなるっていうのがあって、
やっぱりセルフホステッドも空いてたら早くなんだけど、
一気に7本とか走るケースもあるから、
そうなると道々に詰まって、
CPUとか、メモリは余裕はあるんだけど、
CPUの食い合いになって、結局GitHub Actionsとトントンぐらいだよねみたいな。
GitHub Actionsって、CPUのコア数で言うと、
無料で使えるのが2コア、2VCPUとかのリソースなんですけど、
僕たちが使っているMac miniとかは8VCPU、
なので4倍ぐらい使えるんだけど、
結局4本同時実行した瞬間に同じぐらいになっちゃうとかで。
そういうことか。
並列で実行すれば実行するほど、GitHub Actionsの方が、
基本は低スペックなんだけど、低スペックのPCが並列で立つみたいな感じになるから、
16とか立ち始めると全然Mac miniよりいいよねみたいな感じになるってことか。
しかもセルフホストのランナーっていうのを設定するって話したと思うんですけど、
要は1ランナーに1ジョブしか割り当てられないんで、
例えばランナーを4設定してて、
CIとして8を動かしたいってなった場合は、
最初に4入って、その後待機列に4つ待ってる状態になるので、
結構待ち時間みたいなのが逆に増えてしまうっていうのも、
セルフホストのデメリットというか、
まずはPCに登録する、セルフホストとして登録するランナー数を、
今のテストとかCIのどれぐらいメモリとかCPUを1回ごとに食うのかなっていうのを計算して、
例えば1回の実行にCPUの10%ぐらいを食うんだなっていうのが分かったら、
ランナーとして登録できるのって最大10本までぐらいだよねみたいな感覚で計画して、
ランナーを設定する必要があって、
僕たちはその計算したところ、大体8本ぐらい並列できそうだなっていうので、
1つのMac miniは8本ぐらい登録していて、
もう1個あるんですけど、それは4本ぐらい登録しているような感じになっている状態ですね。
じゃあMac miniが増えれば増えるほど増やせるみたいな感じなのか、
もしくは1個のPCを強くするのかどっちか分からないけど、
複数台でやることもできるってこと?
そうそう。
でもやっぱりそれでもどうしても待機率ができてしまうっていう問題があって、
でもそれって待ち時間が長くなるので、
結構開発しにくいなって体験が悪くなる方向に走っちゃうので、
僕が今回やったことっていうのは、
最初にGitHub Actionsが起動する瞬間に、
一番最初のステップで各セルフホストランナーに対して、
どれぐらいリソースが空いているのかっていうのを機械的に検査するステップを、
10秒ぐらいかかるんですけど、
10秒だけで終わるステップなんですけど、
それを1個追加したんですよ。
もし埋まってたら、それはGitHub Actions上で回すような仕組みにルーティングしてて、
空いてたらどんどんセルフホストで回すんだけど、
空いてなさそうで、しかも待機時間が一定数超えそうだったら、
諦めてGitHub Actions上で回すっていう設定を、
っていうジョブを1個追加したんですよね。
なんでこういうジョブが必要になったかっていうと、
ロードバランスしたい、振り分けたいっていうところがあったんですけど、
振り分けをするときの設定値っていうのが、
GitHub Actions上には用意されてなくて、
固定値でこの設定を書いたら全部がセルフホストに行くか、
全部がGitHubで回すかの2択しかない状態だったんで、
その設定値を柔軟に切り替えできるようにっていうので、
1個ジョブを作ったような感じで振り分けてるんですよね。
それもいいね、確かに。
結構これはね、バランス、ちょっとどれぐらい振り分けるかみたいなバランスは、
最終的なコストを見て判断した方がいいと思うけど、
これやるとほとんど今待機しないで、
てかもう待機はほぼしないかな。
で、セルフホストが使えるならバンバン回すしみたいな、
とかできてるんで、結構良かったなと思ってますね。
そうすると今までレビューをね、
例えばオープンコードでレビューしてもらうようにする、
みたいなのとかも動かせるようになるから。
そうだね、やりやすくなるよね。
やりやすくなるよね。
NixOSからUbuntu 24へ変更
あとちょっと僕やってて注意した、注意というかハマったポイントがあって、
あれなんですよね、
NixOSを最初使おうとしてたんですよ。
Nixで管理する、Nixっていうシステムを管理するソフトウェアで管理をするにあたって、
そのソフトウェアが提供してるNixOSっていう、
LinuxOSのディストリビューション、要は派生があるんですけど、
それを使った方が全てを管理できるので、
よりやりやすいなっていうのがあったので、
最初はNixOSを選択したんですけど、
Prisma、タイプスクリプトの、
JavaScriptで使えるSQLクライアントであるPrismaが、
NixOS向けのエンジンを配布していないっていうのがあって、
最初はNixOSで起動して、
E2Eテストとか、データベースに関わるようなテストを回そうとしたら落ちるっていう問題が起きたので、
これは諦めてNixOSではなくて、
Ubuntuを使ってるみたいな感じになってますね。
なるほど。そういう制約もあるのか。
あと、これはちょっとどうなのかわからないんですけど、
E2EをやるときにChromiumを使うんですけど、
Chromiumをなんで使うかっていうと、
PlaywrightっていうE2Eテスト用のソフトを使ってるんですけど、
それがARM64っていうアーキテクチャに依存しているっていうのがあって、
Ubuntuの26系はARM64に対応していなくて、
使えなかったみたいな問題が起きてたので、
あえなくそこはUbuntu24で動かしていって、
OSとしてちょっとバージョン古いんですけど、
一応問題はないかなっていうので、
一旦Ubuntu24で動かしていって、
この2つのハマりポイントが結構あったと思いますね。
なるほど。
その辺はでも基本的にはもうAIが、
あとはもう自己検証して、
とにかく回るところを保証しましょうって話をしたら、
自分で考えてくれたので、あんまり手間はかかってないです。
PCにしたらそれだけ早くなるし。
そうだね。あとはPCの台数を増やすっていうのも結構あるかな。
コスト比較しやすいからいいね。
例えばうちみたいになったら、
月間300ドルかかってますってなった時に、
年間で3600ドルかかってて、
1年でこんだけ回ってるんだったら、
PC1個用意するかみたいなとか、
そういうことが考えられるみたいなのは。
そうだね。
Oracle CloudとUbicloudの活用
あとパソコン、そもそも手元にないよみたいな。
自分の開発用PCしかなくて、
そんなMac miniなんてちょうどよくないよみたいな人向け。
僕もこれ試してみたいんですけど、
けちけち構成的な話で言うと、
オラクルが無料枠でコンピュータリソースを貸し出してくれるのがあって、
クラウドA1っていうインスタンスを選択すると、
24時間動かせて、
無料アカウントだと4CPUの12GBのメモリまで24時間使えるっていう、
24時間365日ずっと使って続けても無料っていうのがあって、
これを使うと結構CI回せるので、
これをまずやってみるのもありですね。
うちもね、わざわざ買ったというよりは、
ちょうどパソコンを買い替えたタイミングで、
っていうのもあったから。
あったからそれにしてるみたいな感じのところあるかな。
確かに。
あともう一つが、
Ubicloudっていうのがあって、
これもオラクルみたいな感じで、
コンピュータリソース貸し出してくれるんですけども、
GitHub Actionsの利用料、これは有料なんですけど、
GitHub Actionsで使うよりは、
結構コスト安く動かせるみたいだったので、
これも選択肢の一つになり得るよねっていうところと、
1250分分のクレジットが毎月付与されるんで、
だいたいこれ2.5ドル分なんですけど、
これをやれば、少なくとも1250分分は無料で動かせるので、
これも候補になるかなと。
GitHub Actionsと併用できるってこと?
そうです。
セルフホストランナーとして動かすので、
これはGitHub Actionsと併用できるから、
オラクルのクラウドA1とUbicと、
他にも多分無料になるような、
インスタンスを出しているVPC屋さん、
サーバー屋さんっていうのはいくつかあると思うんで、
そういうのをいろいろ探して、
分散させるってことで、
すごいケチケチ構成するって、
一つの選択肢に上がり得るのかなって思いますね。
なるほどね。
GitHubすごいね。
ボロ儲けでしょうね、今は。
前にGitHub Actionsが課金にかかるから、
みんながセルフホストに動く流れが、
今まさに起きてると思うんですけど、
Xとか眺めてても。
あとは取引先の開発者さんとかでも、
セルフホストで動かすようにしました、
みたいな話もあっちの方に聞くようになっている中で、
ちょうど去年ぐらいか一昨年ぐらいに、
実はセルフホストにも課金するぜみたいな、
GitHubがアナウンスを出して1回。
そっち分でも、
GitHub Actionsで動かすよりは割引するけど、
それなりに課金は取るからね、
みたいなアナウンスをしたところを、
猛烈に批判を浴びて、
数時間後にやっぱやめます、
みたいな動きが実は昔あって。
なのでもしかしたら今後、
セルフホストでも課金マージン取るわ、
みたいな話が出てくるかもしれないかなっていうのは、
ちょっとありつつも、
だいぶそれでコストカットは果たせそうかなっていう。
なるほど。
ありがとうございます。
いろいろと効率化してください。
だいぶコスト減らせたんじゃないかなと思ってます。
空きMac miniでAIセッションを動かす
あと最近は、
セルフホスト用のMac miniが今2台あるんですけど、
CI回してる時間って実はそんなに多くなくて、
GitHub Actionsとかで回してる時間ってそんなに多くないっていうと、
さっきまで言った14万分なんなんだって話あるかもしれないですけど、
あれってめちゃくちゃスパイク的に、
ある瞬間の時間だけ大量に並列実行されて、
延べ時間として14万分かかってるだけで、
人間時間の24時間で見たときに、
ぶっちゃけそのCIが動いてる時間って、
せいぜい60%から20%から40%ぐらいしか実行されてないっていう、
今僕たちのチームではそういう状況にあって。
そうなるとパソコン買ったとして、
セルフホストに回したとしても、
可動時間って実は40%ぐらいが高止まりなんだなっていうところになった。
残り60%の実行時間が丸々無駄になるなっていうふうに思ったんですよね。
なので最近やった取り組みとしては追加で、
僕たちがAIをローカルで動かすときに、
クロードコードとかオープンコードを立ち上げるんですけど、
それを自動的に空いているMac miniで起動するような仕組みを作って、
オープンコードとかクロードコードとかコーデックスって、
一回起動するとメモリをパソコンの中で1ギガぐらい確保したりして、
結構並列で開発してるとパソコンがちんちんに厚くなって、
すごい重くなるって問題があったんで、
外部の動いてないときはそっちで動かすようなリモートセッションみたいな機能を
ちょっと今動かして、ようやく今動くようになったんで、
完全に今用意されてるMac miniが稼働率100%になるように、
よりケチケチな爪爪に動かす仕組みを作ってるって感じですね。
それめっちゃ助かるよね。
これね、ちゃんと動けば、まだ使用段階なので、
全てがちゃんと動いてる感じはないですけど、
僕テストしてる感じだとオープンコードとか勝手に起動して、
そっち側で動いて終わったら自分のパソコンに回収されるみたいな感じになったんで、
かなり良くなったと思います。負荷が下がって。
いいっすね。それができるってことはね、
高性能なPCがあったらそっちにルーティングして、
そっちはローカルLMとかそのPCを使って動かすとかができるようになると、
なんか夢があるよね。
夢ありますね。いろんなことができるんだなっていう。
この仕組み作るのかなり大変だったんですけど、
一回この仕組みさえできれば、いろんなものがね、
オーケストレートできるというか、かなりいいですよ。
ありがとうございます。
ちょっとまた引き続き、ちょっと工夫点とかあったら
共有してもらえたらと思います。
じゃあ、結構40分ぐらい経ったので、
今日はこれにて以上にしましょうかね。
なんか最近の、今後あれにしようかな。
ちょっとした気になるトピックみたいなのをちょっとだけ入れるみたいな感じにしますか。
終わりがけに。こういう普段の日常のやつと、
あと、今日とかだとハイクが公開されたねみたいなとか、
ちょっとトピックをいくつかみたいな感じにして、
ニュース的な感じでやっていけたらと思います。
今日はやりませんか。
じゃあ、ありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。
いかがでしたでしょうか。
今回はAI駆動開発していると、
大きい組織だともっとネックになってくるんじゃないかなと思うんですけれども、
GitHub Actionsの課金がめちゃめちゃ増えすぎるっていうところ。
あと、PCスペックによっては、
CIを待っている時間もったいないよねっていうのは課題としてあるかなと思うんですけれども、
それを早くする方法にもなり得るかなというふうに思うんですけれども、
そちらの阿部ちゃんにやってもらった工夫みたいなところを共有いただきました。
こんな感じで日々AI駆動開発をやる中で、
感じた課題をどういうふうに改善しているのかとか、
ひっくるめて話しておりますので、
もしこんなトピック話してほしいとかあれば、
コメントいただけると大変嬉しいです。
このPodcastを気に入ってくれた方は、いいねやフォロー、高評価ぜひお願いいたします。
それではまた次回もお楽しみください。
バイバーイ。
