「10年超えRails開発の振り返りと未来 - 持続可能な開発の具体策」の発表資料です https://pieceofcake.connpass.com/event/324722/
成果 最終的に、Cloud Run のコストが$6/day前後から$1/day前後に! ちなみに、Cloud Tasks は1ヶ月あたり最初の100万回のオペレーションまで無料なので余裕で収まっています。 モチベーション 今回リプレイスを検討したシステムは軽量な非同期処理が大半で、もともと絶対に Sidekiq でないと困るということが少なかった Sidekiq は Redis をポーリングしてジョブを取得する方式なので、Cloud Run で実行するには min-instances を1以上にしなければいけない 何もジョブがない状態が続いてインスタンスが0になると起こしてくれる人がいないので... 絶対に Sidekiq でないと困らないなら Cloud Tasksにして、非同期処理がない時は寝ていても良いようにしたい => コストダウン! Pub/Sub との比較検討もしましたが今回は
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Smooth Ruby and Rails upgrades | Arkency Blog 原文公開日: 2024/07/01 原著者: Posts by Piotr Jurewicz 日本語タイトルは内容に即したものにしました。 参考: Rails アップグレードガイド - Railsガイド 最近、私たちは年季の入ったさまざまなプロジェクトでコンサルティングやアップデート作業を行っていました。どのプロジェクトもproductionで運用されていてビジネスを回していますが、長年アップグレードされないまま放置されていました。 こうしたプロジェクトでの経験を活かして、アップグレード作業をスムーズにするための知見を本記事でいくつか共有したいと思います。 🔗 アップグレード前にやるべき作業 🔗 依存関係をできるだけ減らしておく 作業
Datadog Continuous Profiler を用いて、ボトルネックが Ruby の GVL であることを発見した こんにちは、terandard です。 弊社では Datadog を用いてアプリケーションやサーバーの監視を行っています。 以前からリクエストがスパイクした際にアプリケーション全体が遅延する問題があったので、Datadog Continuous Profiler を使用して調査したことについて紹介します。 背景 リクエストがスパイクするとアプリケーション全体が遅延する問題がありました。 リクエスト全体のリクエスト数とレイテンシー 特に処理に時間がかかっていたリクエストについて Datadog APM で状況を確認すると、下図のように空白期間があったり mysql2 や faraday の実行時間が長いことがわかりました。 例1: 謎の空白期間がある 例2: mysq
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
このSpring Bootを使ったクリーンアーキテクチャの例は、データの詰め替え過剰にみえる。 https://www.baeldung.com/spring-boot-clean-architecture これだけのモデルと詰め替えが必要なのだろうか? 『Get Your Hands Dirty on Clean Architecture 』にこのマッピング戦略(詰め替え戦略)が書かれている No Mapping (レイヤ間でモデルを共有し、詰め替えをしない) 2-way Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しは上位レイヤが詰め替えの責務を負う) Full Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しには専用のモデルを使う) またこの戦略のどれを選ぶかの基準は『Balancing Coupling in Software Design
はじめに はじめまして、IPUSIRON(@ipusiron)と申します。現在はIT技術書の執筆を本業としつつ、FIRE生活を過ごしています。 最初の本が出たのが2001年です。途中で学生や会社員だった時期もありますが、20年以上執筆し続けていることになります。その間、30冊を超える本を執筆してきました。 このたび、「IT技術書を執筆して、FIREをどう実現したのか」というテーマのコラムを寄稿する機会をいただきました。これまでのキャリアを振り返りつつ、次に示す内容を紹介します。 IT技術書の執筆活動を続けてきた中で、印象深い出来事 IT技術書を執筆するということ IT技術書を執筆して、FIREを実現した理由や経緯 自らのキャリアを振り返って、他のエンジニアの方々に伝えたいこと Xでは、読書や執筆に関することを日々発信していますので、気軽にフォローしてください。 はじめに IT技術書の執筆活
初めて使ったBIツールはLooker Studioのid:syou6162です。これまでTableau / Looker(≠ Looker Studio) / Metabase / Redash / Connected Sheetsなど色々なBIツールを触ってきましたが、不満は色々ありつつも個人的に一番しっくりきて愛着があるのはLooker Studioです。このエントリでは、その魅力と便利な使い方や注意点について書きます。例によって、社内勉強会向けの内容を外向けに公開しているため、内容の網羅性などは特に担保していないことにご注意ください。 Looker Studioの魅力 利用のハードルが限りなく低い & Google Workspaceとの連携が便利 複雑過ぎることができないので、諦めが付けやすい ちゃんとBIツールになっている Looker Studioの便利な使い方 多様なデータソ
Amazon Web Services ブログ AWS 上で大規模な GitHub Actions のセルフホステッドランナーを使用する際のベストプラクティス 注記: お客様は自身の GitHub ランナーを管理する必要がなくなりました。AWS CodeBuild を使用すると、管理された GitHub Actions セルフホストランナーを利用できるようになり、強力なセキュリティ境界と低い起動レイテンシーを備えた一時的でスケーラブルなランナー環境を提供します。CodeBuild を使えば、独自のインフラストラクチャを維持したり、スケーリングロジックを構築する必要がありません。すべてが CodeBuild によって完全に管理されます。開始するには、単に Webhook を作成して、CodeBuild で GitHub Actions ジョブを自動的にトリガーするだけです。 概要 GitHu
自身の過去の成長過程と現在の環境を思い浮かべたときに、得やすいもの得づらいものの違いを強く感じ、良好な成長のために一考してみた次第です。 といっても既にある Tweet のセルフまとめに、思い出と昔話なポエムを追加したようなチラ裏回です。 時代の変遷によるステータス変化 要約すると、現代は技術力の向上に必要な環境と既定路線があって向上速度が早いのに対し、昔(2010年以前とか)は頭を悩ませまくって乗り越えるべき壁が大量にあったおかげで解決力は相当鍛えられたよねってところ。 個人的には誰であれ、今!自分が!解決しないと!詰んでしまう!! てかもう詰んでるだろコレ!!!! って状況でひたすら悩んでから、寝て起きたら解決したよぉ!みたいのを体験してほしいし、一度は死の淵まで行ってこいって思っている — 外道父 | Noko (@GedowFather) July 17, 2024 これについて、
どうも、すべての経済活動を、デジタル化したい福島です。 本日はLayerXが挑戦するコンパウンドスタートアップについて解説したいと思います。 コンパウンドスタートアップとは、Ripplingという米国のスタートアップ のCEO Parker Conradさんが提唱しているスタートアップの新たな競争戦略です。Parker Conradさんはユニコーン企業Zenefitsの元CEOであり、Zenefitsでの失敗の経験を元に、Rippplingを創業。コンパウンドスタートアップという従来のセオリーとは異なるやり方で大成功を収めています。 Ripplingは20年8月にユニコーン入りしており、日経記事でも紹介されています。 TLDR(長すぎて読めないよという方に) コンパウンドスタートアップとは 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供 部署でサービスを区切るのではなく、デ
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: How to add index to a big table of your Rails app | Arkency Blog 原文公開日: 2024/06/13 原著者: Szymon Fiedler 日本語タイトルは内容に即したものにしました。 成功したアプリケーションでは、一部のテーブル(usersテーブルなど)がかなり肥大化することがあります。ご興味がおありでしたら、データベースのパフォーマンスを定期的にチェックしてみましょう。メトリクスで遅いクエリが見つかったら、インデックスを付け忘れている可能性が高いでしょう。 🔗 DBエンジンの現状をチェックしよう 現代のデータベースなら、ほとんどの場合非同期かつ非ブロッキング方式でインデックスを作成可能ですが、そのデータベースのルールにどんな例外があるかをもれなく理解しておく
はじめに こんにちは!株式会社スマートバンクでサーバサイドエンジニアをしている @nagasawa です。 2024年6月より弊社では Ruby 3.3.2 を本番アプリケーションで稼働させ始めたため、バージョンアップ前と比較してどの程度パフォーマンスに変化が現れたのかをご紹介いたします。 また、今回を機に YJIT Metrics の可視化と YJIT の遅延起動にも取り組んだため、その手法や効果についてもこの記事内でシェアできればと考えています。 前提 下図のシステムアーキテクチャ図の通り、弊社では Ruby と Rails で開発されたいくつかのシステムを稼働させています。 この記事では core-api と呼ばれている私達が開発してる「家計簿プリカ B/43」の機能のほぼ全てを提供しているシステムのパフォーマンス変化をご報告いたします。 バージョンアップ前 バージョンアップ後 Ru
目次 開発生産性を掘り下げるサービスたち 生産性 = 産出量 / 投入量 生産性を向上させる3側面による整理 ①メソッド(生産方式や業務処理方法) ②パフォーマンス(能率や業務実施効率) ③ユーティライゼーション(計画や活用のうまさ加減) (余談) SPACE フレームワークについて 生産性関連データの可視化で何を見いだせるのか アウトカムの厳密な可視化は難しい 機能としてはアウトプットの可視化に比重が寄る 生産性の可視化を必要としないこともある 可視化された情報から何ができるのか アクティビティ傾向の変化や異常の発見 意思決定における再現性の担保 説明責任における透明性の担保 総じて、すべきでは無いこと 速度と量の回し車にしない 意味を見いだせない指標を運用しない どうぞご健康で! 開発生産性を掘り下げるサービスたち 開発に関わるインテリジェンスを提供する SaaS には国内では私が勤め
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。 効果・成果よりも効率を優先することは生産性か? 開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。 などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ|610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論
七夕の夜、小池知事の当選確実が報じられた後、あいさつする安野さん。「素直に悔しい」「本当に意味のある成果」「日本の政治を変えていきましょう」。誠実な人柄であふれていました。 そして、短冊の願い事を見て改めて感じました。 いいチームですね。#安野たかひろ https://t.co/8LVzKlqRLq pic.twitter.com/cpvyotLAv1 — 山本浩資@サンデー毎日編集次長 (@KosukeYAMAchan) July 8, 2024 ▲会の終盤には記者さんにもお越しいただけました 今回の記事では、7月7日の振り返り会でそれぞれのメンバーが発表したKPT(Keep/Problem/Try)を公開いたします!メンバーの熱い思いが結集した結果、振り返りの分量は文字数にして3万字超え、項目は518にものぼりました。 このnoteではその内容をギュッと凝縮して、お伝えいたします!
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く