MCPサーバーを使うなら Prompt Caching が大切だと思い知った話
MCPサーバーと連携するアプリ使ったら、利用料が高かった MCPサーバーと連携するチャットアプリを作っていたのですが、「開発中でほぼ自分しか使ってないのに生成AIの利用量がやたら高くね？」と思いました。 ClaudeのMaxプランが月額100ドルで使い放題であることを考えると、開発中に軽く使っただけで数千円かかるアプリなんでコスパ悪すぎて、まともに使えないですね。 調べてみた なぜそんなに高いのか分からなかったので、Claudeのログを取って調べてみました。 ログの取り方は先日書いた記事を参照ください。 そして、取得したログを確認したところ、、、 {"input_tokens":21786,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"output_tokens":85}} "input_tokens":21786
npm ciのキャッシュ方式の検討
結論から言うと、node_modulesをキャッシュしてnpm ciの実行を省略するのが、多くの場合には有効そうです。 はじめに CIで npm ci を使うとき、実行時間短縮のためにキャッシュの利用を検討することになると思います。このとき、どのようにキャッシュするのが良いのでしょうか？ よく知られているキャッシュ方式として、以下の二通りの方式があります。 ~/.npmをキャッシュする方式 node_modulesをキャッシュする方式 それぞれの違いについて、詳しく見てみましょう。 ~/.npmをキャッシュする方式 npm ci を実行すると、POSIX系のOSではデフォルトで ~/.npm にキャッシュデータが書き込まれます。package-lock.json をキーにこのディレクトリをキャッシュしておくことで、次回以降の npm ci 実行時にこのキャッシュデータを利用しよう、というの
やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
GitHub ActionsでGoのコンテナイメージをビルド・プッシュする際のベストプラクティスを考える
この記事は MICIN Advent Calendar 2024 の 24日目の記事です。 前回は菅原さんの、「MiROHAのエンジニアとして入社してみて」 でした。 はじめに 本記事では、GitHub ActionsでGoのコンテナイメージをビルド・プッシュする際のベストプラクティスを検討、紹介します。特に、キャッシュをどう設定するかに主軸を置いて展開していきます。 Goのコンテナイメージのビルド・プッシュに関する公式ドキュメント、記事などはたくさんある一方で、実際のプロダクト開発でどうCIを組めばベストなのか、計測まで行って比較検討したものは筆者の観測する限りほとんどありません。そのため、取り入れてみても思いの外改善しないな…となることが多いです。 そこで、2024年12月時点で考えうる手順をいろいろ計測しながら試してみて、ベストプラクティスを提示してみようと思います。 なお、筆者のプ
Docker Engine 18.09 から使える Build-time secrets を試してみた | はったりエンジニアの備忘録
Docker Engine 18.09 から Build-time secrets という機能が使えるようになりました。この機能を使えば docker build するときに secrets (API key, credentials, etc) を安全に取り扱えるようになります。 Introducing Docker Engine 18.09 - Docker Blog Integrate secrets in your Dockerfile and pass them along in a safe way. These secrets do not end up stored in the final image nor are they included in the build cache calculations to avoid anyone from using the c
2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
LINEはなぜBazelを使わないことにしたのか？
Jung Giuk2023-08-292019年 LINE に Build Engineerとして入社し、現在は「アプリプラットフォーム開発室」のディベロッパーエクスペリエンス開発チームに携わっていて LINE iOSアプリのビルド環境やコードクォリティの改善に取り組んでいる。 はじめに こんにちは、ディベロッパーエクスペリエンス開発チームのJungです。 この記事では２年以上 LINE iOSのビルドシステムとして運用したBazelをやめることにした背景についてご紹介します。 Bazel導入とこれまでのLINE iOS LINE iOS は200万行以上のソースコードと200以上のモジュールで構成される大規模プロジェクトです。 LINE iOSのソースコードとモジュールの数が増えて規模を拡大し続けるにつれて、ビルド/テストの遅延と DX(デベロッパーエクスペリエンス) の低下という避けら
Docker Build Cloudを導入してコンテナイメージビルド時間を80%削減しました
背景弊社では効率的で迅速な開発プロセスを維持するためにコンテナ技術を使用しています。 これまでもコンテナイメージのビルド時間を短縮するための改善を行ってきましたが、今回のDocker Build Cloudの導入により、ビルド時間を大幅に短縮することができました。この改善によって、プルリクエストごとの検証環境を迅速に作成し、デプロイフローをより速くすることが可能となりました。 成果まず最初に成果を共有します。 今回、Docker Build Cloudを活用することで、コンテナイメージビルド時間を劇的に短縮することに成功しました。具体的には、従来約6分30秒かかっていたイメージのフルビルド時間が、約1分10秒まで短縮されました。この結果、ビルド時間を80%削減することができました。 コンテナイメージビルドにおける課題今まではコンテナイメージビルドの高速化のため Registry cache
actions/cache@v4ではヒットしなかったときcache-hit=='false'にならない - ぽよメモ
[追記 2024/8/1] 修正のPRがマージされました [追記 2024/10/9] 修正がリバートされました cache-hitとは v4における挙動変更（？） cache-hitがfalseを返さない ワークアラウンド [追記 2024/8/1] 修正のPRがマージされました まだリリースされていませんが次のリリースに含まれるでしょう。 github.com [追記 2024/10/9] 修正がリバートされました v4.1.0で修正された本変更だが、空文字になるという挙動に依存していた人が予想よりも多く、元の挙動に戻すという決定がされた。 github.com v4.1.1ではこの記事の通り cache-hit=='false' にならず、空文字が返る。 詳しくは以下のコメントを参照して欲しいが、そもそも cache-hit というパラメータの表すものが難しく、将来的にはパラメータの
なんでbun installは速いのか？
A global install cache. bun installを実行すると ~/.bun/install/cache/ 以下にnpmレジストリからダウンロードされたファイルの実体が展開されキャッシュされる(--cache-dirでパスを変更できる)。 キャッシュにはパッケージのバージョンごとのディレクトリとlatestのシンボリックリンクがある。これらのファイルを使ってbun install時に該当するバージョンのダウンロードを省く(--forceで再ダウンロードする)。 このため一度bun installしてlockfileが作成されると次はオフラインでinstallを実行しても成功する。 node_modules/を削除しても~/.bun/install/cache/からファイルを取ってくるのでネットワークアクセスをしない。
速く、もっと速く！Docker Build Cloudでイメージビルド時間を短縮する - 世界中の羊をかき集めて
2024/1/23に Docker Build Cloudが発表されました www.docker.com 早速Docker Build Cloudを試してみました Docker Build Cloudとは サイト: https://www.docker.com/ja-jp/products/build-cloud/ ドキュメント: https://docs.docker.com/build/cloud/ イメージビルドをDocker社のCloud環境で行える機能です。 これによりどのようなメリットがあるかというと イメージビルドキャッシュの共有 ローカルでイメージビルドするとき、もし他のユーザがビルド済みであればそのキャッシュを使うことができビルド時間が短縮できる CI環境では毎回サーバーが違うため--mount=type=cacheが効かないがDocker Build Cloudであれば
Docker Buildにおけるリードタイム短縮のための3つの改善ポイント | PLAID engineer blog
こんにちは、エンジニアの oga です。2019/12に入社してプロダクト開発業務に携わっています。 プレイドでは、KARTE の開発及び実行環境としてDockerやk8sを活用していていますが、私自身はこれまでPaaSやFaaSなどのコンテナ管理が隠蔽されている様な形やそもそもコンテナを使わない開発が多かったので、Dockerfileに構築のコマンドを書き連ねてdocker build でバシッとイメージができる便利！ぐらいの理解度でした。 今回はそんな中から基礎として学んだDockerfileのベストプラクティスを、 リードタイム（CI/CDの実行時間）を短縮し開発生産性を向上させる為に行うべき事 という観点でまとめました。 大筋は 公式のベストプラクティス に挙がっている手法を理解し易く整理し、重要だけど分かり辛い部分を解説する内容になります。 3つの改善ポイントDocker Ima
cache を最適化して RuboCop の CI 実行時間を劇的に改善した話 - JMDC TECH BLOG
こんにちは、プロダクト開発部の八杉です。JMDC では主に web フロントエンドの実装や設計を中心に行っているほか、最近は Rails の GraphQL モジュールの設計や CI の最適化にも取り組んでいます。 本記事は JMDC Advent Calendar 2023 11日目の記事です。 qiita.com この記事では、 RuboCop を CI で実行した際に遭遇した cache にまつわる 3 つの問題とその対処について紹介します。 背景 今回お伝えするのは、私が開発に携わる Pep Up (ペップアップ) という web サービスの話です。 Pep Up は Ruby on Rails 製のアプリケーションで、コードフォーマッターに RuboCop を使用しています。8 年前の開発初期から使用していますが、違反のチェックを厳格に行っていなかったこともあり、ここ数年はフォー
Prettier's CLI: A Performance Deep Dive · Prettier
Hey, I'm Fabio and I've been contracted by the Prettier team to speed up Prettier's command line interface (CLI). In this post we'll take a look at the optimizations I've discovered, the process that lead to finding them, some exciting numbers comparing the current CLI with the new one, and some guesses about what could be optimized next. Installation The new work-in-progress CLI for Prettier has
ServiceWorkerの落とし穴8選 - Repro Tech Blog
はじめに Reproで開発を担当しているEdward Fox (edwardkenfox) です。2021年頃から Repro Booster というプロダクトの立ち上げに携わっており、開発を通して得た知見を共有できればと思い立ち筆を取るに至りました。4年ぶりのテックブログ執筆で少しばかり緊張していますが（？）、張り切ってやっていこうと思います。 Repro Boosterとは 2022年11月に正式リリースした、ウェブサイトの表示速度向上を実現するサービスです。「タグを入れたその日から、Webサイトが速くなる」というタグラインのもと、タグ（JavaScript）の設置だけでウェブサイトの表示速度が簡単に実現できるということで、リリース以来多くのお客様・サイトでご利用いただいています。 Repro BoosterではServiceWorkerと呼ばれる技術を最大限活用して多くの機能が実現さ
Next.js の fetchCache を考える
Next.js App Router は global のfetch関数に patch をあてており、自動でデータ取得が最適化されるように設計されています。そのうちの一つが、取得したデータをキャッシュし、再利用する最適化です。キャッシュされた取得データは、必要に応じて任意のタイミングで Revalidate（データ再取得・キャッシュ更新）が可能です。本稿はこのfetch関数を経由してキャッシュされる「fetchCache」について、どのように向き合うべきか考察したメモです。 検証留意点 はじめに、筆者が検証にあたり留意した点を書いていきます。本稿を読んでみて「自分でも検証してみたい！」となった方は、参考にしていただければと思います。 【1】取得データがキャッシュされるタイミング タイミングは２通りあります。 ビルド時: next buildで Next.js アプリをビルドした時 リクエス
Vercelのキャッシュを完全に理解しました (?)
はじめに 先日(2023/5/1)にVercelの新機能・サービスを発表するビッグイベント 『 Vercel Ship 』 が開催されました。 Next.jsやVercelの激アツな発表がたくさんあり、非常に大きな盛り上がりを見せているように感じます。 今回は、最近社内でも活用されているISRという技術を支えるstale-while-revalidateに触れつつ、Vercel(with Next.js)のキャッシュについて、最低限知っておきたい知見について共有できたらなと思います。 Vercelのインフラストラクチャ概要 Vercel Edge Network を使用すると、顧客の近くにコンテンツを保存し、データに近いリージョンでコンピューティングを実行できるため、待ち時間が短縮され、エンドユーザーのパフォーマンスが向上します。 エッジ ネットワークは、コンテンツ配信ネットワーク (CD
ジョブを細かく分けてGitHub Actionsのテストを効率化する
改善戦略 実行のタイミングやGitHubの状況や依存サーバーのネットワークの状況によって変動はあるものの、早くて7分、だいたい10分〜15分くらいかかっている。早いか遅いかは、他の開発と比べても内容や状況が違うのでなんとも言い難いが、個人的な感想としては「遅い」。というより、一切の工夫をしていなかったので、もっと早くできるはずだと考えた。 ビルドされたファイルを複数の環境で共有する 処理全体の中で時間がかかっている処理は3つ。 依存パッケージのインストール ビルド テスト さらに、課題の一つとして「テスト実行時に開発用依存パッケージ（devDependencies）がインストールされているせいでテストが失敗しない問題がある」というものがあり、これを処理に追加しないといけない。 開発用依存パッケージのインストール ビルド 依存パッケージを一旦すべて削除 本番用依存パッケージのインストール テ
Cache Storage がめちゃくちゃ肥大化する問題について調べる | ぴんくいろにっき
Cache Storageがめちゃくちゃ肥大化する問題 TBSのニュースサイト、TBS NEWS DIGがめちゃくちゃブラウザのストレージを消費しているという話がはてブや増田で話題になっています。 TBSのニュースサイトヤバない？ – はてな匿名ダイアリー 同・はてなブックマーク 確かに、手元でも同様の状況を観測できる。 当該サイトのストレージ使用状況 はたして、これは真実なのだろうか。本当に1.4GBも食うことがあるのだろうか…… そんなわけない、ということで調査 まずは再現性を確認するためにChromeのゲストモードで当該のサイトのDevtoolを開いてましょう。すると、StorageのUsageは386MBになっていました。（適当なページを開き、リロードした時点で340MB程度であった） 当該サイトのストレージ割合 上記のスクリーンショットをよく見ていただけるとわかると思いますが、こ
メルカリShops のフロントエンド | メルカリエンジニアリング
こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載：「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか？ アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
