はてなブックマーク

こんにちは。タイミーでプラットフォームエンジニアをしている菅原です。普段はAWSを中心に、インフラの設計と運用に取り組んでいます。 今回は、ランサムウェア対策として構築したバックアップと、そのバックアップが正しく機能していることを継続的に監視する仕組みを紹介します。 ランサムウェア攻撃は、データを暗号化したり盗んだりするだけでは終わりません。復旧そのものを妨害するために、既存のバックアップまで削除や改ざんの対象にするケースが増えています。この脅威に備え、私たちはAmazon Auroraクラスタのバックアップを、クロスアカウントの論理エアギャップVault（Logically Air-Gapped Vault、以下LAGV）へ継続的にコピーする仕組みを作りました。 ただ、実際に手間がかかったのはバックアップの経路を組むことよりも、それが本当に機能し続けているかを検証することでした。設定上は

はじめに こんにちは、タイミーのプラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 この記事では、スキマバイトサービス「タイミー」のバックエンド（Rails API）に Datadog Test Impact Analysis（TIA） を導入し、PRごとのCIフィードバックを大幅に高速化した取り組みについて紹介します。 なお、バックエンドはRailsアプリケーションなので、テストフレームワークは RSpec を前提として話を進めます。 サービスが成長してプロダクトの機能が増えてくると、テストも当然増えていきますよね。開発者が増えればPRの数も増え、CIの待ち時間がボトルネックになってくるのも、割とあるあるな課題だと思います。同じような悩みを抱えているチームの参考になれば嬉しいです。 背景：膨れ上がるテストとの戦い タイミーのバックエンドはモジュラーモノ

はじめに 株式会社タイミーのプラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 突然ですが、皆さんの組織では「3ヶ月前のログを見たいんですが……」という依頼が来たとき、どう対応していますか？ タイミーではDatadogをログ基盤として利用しています。Datadogは日常的なログ検索やアラート、ダッシュボードなどに使える非常に強力なツールです。一方で、ログの保存にはそれなりのコストがかかります。そのため弊社でも、コストとのバランスを考えてログの種類ごとに14日〜長くても45日程度の保持期間を設定していました。 普段の運用ではこれで十分です。ただ問題となるのは、「保持期間を超えた過去のログを検索したい」という場面が来たとき。今回はこの課題に対してDatadogのFlex Logsを導入し、コストをほぼ変えずに長期ログ検索を実現しようとしている取り組みについて

こんにちは、タイミーでバックエンドエンジニアをしている 福井 (bary822) です。 タイミーのバックエンドは巨大な Rails のモノリスアプリケーションです。以前から「アクセスが集中する特定のテーブル（以下、人気テーブル）への DB マイグレーションが日中に通らない」という問題を抱えており、看過できないレベルになってきたため、本格的に対処に乗り出しました。 この記事では、原因となっていたロングトランザクションに対し、Datadog と Devin を組み合わせた自動修正フローで対処した話と、その設計の裏側を紹介します。 DBマイグレーション失敗のメカニズム 日常的に発生していたのは、人気テーブルへの ALTER TABLE が日中はほぼ通らない、という状況でした。原因は メタデータロック (MDL) です。 Aurora MySQL(8.0) では、SELECT / INSERT

はじめに こんにちは。タイミーで Platform Engineer をしている小河原（@kgwryk28）です。 現在、タイミーのシステムで利用しているメインのデータベース（Aurora MySQL）のバージョンアップを進めています。前回の記事では、アップグレードに伴う SQL の互換性や性能の検証について共有しました。 この記事では、そのアップグレードと並行して取り組んでいる Aurora MySQL の GTID モード有効化 を行うにあたって直面した課題と、それぞれをどう解決したかを紹介します。 GTID やレプリケーションに詳しくない方にも読んでいただけるよう、必要な前提はその都度補足しながら説明します。 背景 きっかけは、現状利用しているAurora MySQL 3.x 系（MySQL 8.0 相当の互換性）から Aurora MySQL 8.4 系（MySQL 8.4 相当の

はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 「インスタンスサイズを上げたらコストが下がりました」と言うと、だいたい「？」という顔をされます。スペック上げたらお金かかるに決まってるだろ、と。自分もそう思っていたので気持ちはわかります。 この記事では、Amazon Aurora のReaderインスタンスを db.r7g.8xlarge から db.r7g.12xlarge にスケールアップした結果、I/Oコストが大幅に減り、トータルのAuroraコストがむしろ下がった話を書きます。バッファプールの仕組みと、判断の経緯もあわせて紹介します。 前提：私たちのAurora構成 まず、当時のAurora（MySQL互換）クラスターの構成を簡単に紹介します。 インスタンス クラス vCPU メモリ プロセッサ 役割 reader-1 d

はじめに こんにちは、初めまして。今年3月に入社し、タイミーで Platform Engineer をしている小河原(@kgwryk28)です。 現在、タイミーのシステムで利用しているメインのデータベース（Aurora MySQL）のバージョンアップにおける検証を進めています。 データベースのアップグレードで気になるのは、「今まで動いていたSQLが新バージョンでもそのまま動くのか」「アップグレードによって遅くなるクエリはないのか」という点です。 アップグレード後に互換性の問題や性能劣化が本番で発覚すると、影響は計り知れません。そのため、バージョンアップ範囲内の各バージョンの変更内容（changelog）を調べるだけでは不十分だと感じました。 そこで今回は、Insight SQL Testing を使って検証を実施した際の工夫（期間の絞り込み・重複排除・結果のトリアージ）や検証手順を中心に共

はじめに こんにちは、タイミーでエンジニアをしている徳富(@yannKazu1)です。 タイミーではメインサービスのバックエンドを Rails で開発しています（Go を採用しているプロダクトもありますが、本記事では Rails を前提とします）。 突然ですが、皆さんのチームでは CI の待ち時間、気になっていませんか？ 「Push した、コーヒー淹れた、戻ってきた、まだ回ってる……」みたいな経験は、開発者なら一度はあるのではないでしょうか。 本記事では、そんな状況を改善するために GitHub Actions 上のテスト実行パイプラインで取り組んだ 3 つの高速化テク を紹介します。どれも「知っていれば明日から試せる」くらいの温度感なので、気軽に読んでいただければと思います。 1. キャッシュの保存先を GitHub Cache から S3 に移行 課題: actions/cache が

はじめに こんにちは、タイミーでエンジニアをしている徳富(@yannkazu1)です。 クラウドネイティブ会議2026で発表された「ペアーズ本番環境でのcgroup-aware化との死闘録」がめちゃくちゃ面白かったので、自分の手でも体感したくなりました。 GoのGOMAXPROCSがコンテナのCPU制限を無視するって、実際に見るとどうなるのか？ 過剰並列のスループット低下って、数字で見るとどのくらいインパクトがあるのか？ スロットリングとスレッド数の関係を自分の目でたしかめたい！ 自分で動かして数字を見ないと腑に落ちないタイプなので、ローカルのMac環境で全部再現してみました。 発表の要約 ペアーズのバックエンド pairs-main はGo製でAmazon EKS上で稼働。48コアのNodeで limits.cpu: 5000m（5コア）のPodが動いていたが、GoのGOMAXPROCS

はじめに はじめまして、プラットフォームエンジニアリング本部に所属している徳富(@yannKazu1)です。 みなさん、サプライチェーン攻撃って気にしてますか？ npm パッケージの乗っ取り（ua-parser-js 事件）、GitHub Actions の改ざん（tj-actions/changed-files 事件）、依存パッケージへのバックドア混入（xz-utils 事件）……。ここ数年、OSS を取り巻くセキュリティの前提がガラッと変わってきています。正直、「いつ・どこから仕掛けられるかわからない」状況です。 しかもサプライチェーン攻撃って、攻撃側のコストが低いわりに被害範囲が広いのが厄介なんですよね。 そんなわけで、ECS Fargate 環境におけるサプライチェーン攻撃対策を整理してみようと思ったのですが、いきなり全部を洗い出そうとしてもカオスになるだけ。何かいいフレームワーク

こんにちは、タイミーのバックエンド/Webフロント基盤チーム マネージャーの新谷（@euglena1215）です。 先日開催された RubyKaigi 2026 に参加してきました。その中で特に気になったのが、Shopify の Alexandre Terrasa さんによる「Blazing-fast Code Indexing for Smarter Ruby Tools」という発表です。 この発表では rubydex という Rust 製の Ruby Code Indexer が紹介されていました。RubyLSP や Tapioca に統合することで最大10倍の高速化と2倍のメモリ削減を実現したという内容でした。また、Ruby ツールのための統一的なコードインデックス基盤としてのビジョンも示されていました。Shopify の Ruby DX チームが9名関わっているということで、Sho

はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 新規プロダクトを立ち上げるとき、インフラ構築って意外とやることが多いですよね。その中でも地味にめんどくさいのがDBユーザーの作成と権限付与。手動でやると「あ、権限つけ忘れた」「このユーザー名スペルミスってない？」みたいなヒヤリハットが発生しがちです。 今回は、この作業をTerraformでIaC化した話を書いていきます。 背景：ボイラープレートでインフラ構築を爆速にしている 弊社ではTerraformのボイラープレートと、それをもとにインフラを構築するためのDevinへの指示プロンプトをセットで管理しているリポジトリがあります。 新規プロダクトのインフラが必要になったら、このリポを使ってDevinにお願いするだけ。数時間もあれば、AWSアカウントの作成、VPC・ECS・Aurora

こんにちは！プロダクトエンジニアのkazzhiraです。 私たちのチームでは、2025年の夏ごろから「AI活用による開発生産性の向上」に取り組んできました。しかし、当初の取り組みは抽象的なガードレールの提示や個々人の実践にとどまり、チームとして大きな成果には結びつきませんでした。 その後、SDD（仕様駆動開発）というアプローチに出会い、オープンソースの cc-sdd フレームワークをベースに試行錯誤を重ねてきました。 本記事では、AI開発標準の策定に失敗した経験から何を学び、どのように仕様駆動開発に辿り着いたのか、そして、実践を通じて得た成果と学びをご紹介します。 チームのAI導入でうまくいかなかった話 AI活用の個人最適化 当初、チームでは Cursor、Claude Code、Devin、GitHub Copilot、Gemini などの AI ツールを個々人の判断で利用できる状態でし

はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 先日、本番環境でドキュメントの大規模更新を行った際にCPUが100%に張り付く事象が発生しました。検証環境で同じ更新処理を試しても再現せず、原因がわからない。そこで「そもそも自分、Elasticsearchの中で何が起きてるかちゃんと理解してないな」と気づき、インデキシングから検索までの仕組みを一から整理してみました。 同じように「なんでこうなるの？」と悩んでいる方の助けになれば嬉しいです。 前提知識 本記事では、Shard内部の動作にフォーカスして説明していきます。「そもそもShardって？Segmentって？」という方は、メルカリさんのこちらの記事がとてもわかりやすいので、先に読んでおくことをおすすめします。 全体の流れ まず、大枠の流れを押さえておきます。 インデキシング開始

はじめに タイミーで SRE 業務を担当している徳富（@yannKazu1）です。 日々、数千万件のデータと向き合う中で、Aurora MySQL の運用をより良くするための改善を積み重ねています。 本記事では、その中で経験してきた “机上ではわからないリアルな気づきや学び” を、できるだけ具体的にまとめました。 これから Aurora を本気で運用したい方や、同じような課題に悩んでいる方のヒントになれば嬉しいです。 (この記事はTimee Product Advent Calendar 2025の3日目の記事です。) 1. オンラインDDLでも「ゼロロック」ではない ─ ALTER TABLE 実行時の落とし穴 「MySQL のオンラインDDLなら、日中でもサッと ALTER できるよね？」 ──そんなふうに思ってしまうこと、ありますよね。 たしかにオンラインDDLはとても便利で、データ

こんにちは、タイミーでエンジニアをしている徳富です。 今回は、EKS上にGitHub Actions Self-hosted Runner基盤を構築した話をお届けします。 背景：GitHub Actionsへの移行と、新たに見えてきた課題 2024年10月に公開したCI基盤をGitHub Actionsへ移行した記事で紹介したとおり、 CircleCIからGitHub Actionsへの移行によって、私たちのCI体験は大きく改善しました。 しかし、開発者やテストケースが増え、時間が経つにつれて新たな課題も見えてきました。 実行回数の急増によるコスト高騰 2025年2月頃からDevinをはじめとしたAIエージェントの利用が進み、PRやpushの回数が一気に増加 開発者数の増加も重なり、ワークフロー実行回数が比例して伸びていった GitHub-hosted Runnerは料金や安定性の面である

こんにちは、タイミーでバックエンドのテックリードをしている新谷 (@euglena1215) です。 タイミーのバックエンドは、多くの開発者が関わるモノリスなRailsアプリケーションを中心に構成されています。本記事では、このモノリスリポジトリのデプロイフローを安定させるためにGitHubのマージキューを導入した事例を紹介します。 本記事が、masterブランチにマージしたコードでCIが頻繁に失敗し、開発プロセスに影響が出ているチームの参考になれば幸いです。 masterブランチのCIが頻繁に失敗していた タイミーのモノリスRailsリポジトリでは、1日に20件以上のPull Requestがマージされることもあります。多くの開発者が同時に開発を進める中で、ある問題が頻発していました。 それは「他の人の変更がmasterブランチに取り込まれたことに気付かず、古いmasterを元にしたPul

タイミーでは、Flaky Test がデプロイの妨げになることで開発効率が悪化していました この問題を解決するため、AI エージェント「Devin」を活用し、Flaky Test の検出から修正プルリクエストの作成までを完全に自動化しました 結果、CIは安定し、開発者は本来の業務に集中できるようになったことで、開発体験が向上しました こんにちは！タイミーでバックエンドエンジニアとして働いている 福井 (bary822) です。 皆さんは Flaky Test に悩まされた経験はないでしょうか? タイミーでも、Flaky Test によって CI の信頼性が低下し、開発者の貴重な時間を奪ってしまうという課題を抱えていました。 ある期間においては master ブランチにおけるテスト実行の 4.5% が Flaky Test によって失敗しており、20+回/日 の頻度でデプロイされていることを

読んで欲しいと思っている人 スクラムイベントがうまくいかない感じがして困っている方 スクラムイベントをもっと良くしたいと思っている方 読むとわかること スクラムイベントを改善するための1つのアイデア スクラムイベントは互いにインプットとアウトプットとなりながら循環していること スクラムを改善したい時はシステム思考を勉強するとちょっと助けになること はじめに バックエンドエンジニアを務めている @Juju_62q です。スクラムでのロールとしては「開発者」を務めています。突然ですが質問です。 スクラムイベントがうまく改善できないという経験はありませんか？ 例えば「スプリントプランニングが時間内に終わらない」という問題があるとします。この時にスプリントプランニングで効率的に意思決定を行うための実験を開始してもどうにもうまく問題が解決していかないことがあります。時間内に収めるために強引な意思決定

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 タイミーでは自律型 AI エージェント Devin を活用した開発を行っています。 Devin を効果的に活用する上で鍵となるのが、どのような「knowledge（知識）」を与えるかです。Devin を活用している各社で、試行錯誤が進められているのではないでしょうか。 もし Devin に一つだけ知識を与えて賢くするとしたら、何が最適でしょうか？ 私は「会社固有の知識であり、かつ社員にとっては当たり前すぎて、AIに教えるという発想に至らない情報」が、AIの精度を向上させる鍵になるのではないかと考えています。 社員は知っているが Devin は知らない、そんな情報の代表格として思いついたのが「ユビキタス言語」です。実際に Devin にユビキタス言語を knowledge として教えてみたところ、抽象的な概

はじめに タイミーでPlatform Engineerをしている 徳富(@yannKazu1)です。 2025年2月、私たちの開発組織にAIエージェント「Devin」が導入されました。 Devinは、機能開発のサポートやテストケースの提案など、日々の開発に自然と溶け込む形で活躍してくれていて、今では月に数十〜数百件のマージに関わる頼もしい存在になっています（2025年4月17日時点で489件マージ！）。 そんなDevinと一緒に開発を進めるなかで、ある悩みが浮かび上がってきました。それが「ナレッジの管理が難しくなってきた」ということです。 ナレッジが増えてうれしい、でも…… Devinには「ナレッジ」と呼ばれる、ルールや指針のような情報を登録する機能があります。 「こういうときはこう書く」「こう判断する」など、チームの経験や判断基準をDevinに覚えてもらうことで、より実用的な回答を得るこ

はじめに こんにちは！タイミーでPlatform Engineerをしている @MoneyForest です。 本記事では、タイミーで実施したProduction Readiness Checkの取り組みを紹介します。 Production Readiness Checkとは プロダクションレディネスチェック（Production Readiness Check）とは、「サービスが本番環境で安定して運用できる状態にあるかどうかを評価」するプロセスのことです。 UberのSREの知見から書かれた書籍 プロダクションレディマイクロサービス には、以下のように書かれています。 Uberのすべてのマイクロサービスは、安定性、信頼性、スケーラビリティ、耐 障害性、パフォーマンス、監視、ドキュメント、大惨事（カタストロフィ）対応を備 えていなければならないという8つの原則を考え出しました。そして、サー

こんにちは、Timee でバックエンドエンジニアとして働いている id:ryopeko です。 今回は Timee で使っている API サーバーの Ruby を最新の 3.4.2 (+YJIT) にアップデートしたことについての記事をお届けします。 1. 概要 今回の記事では、Ruby 3.3.6 から 3.4.2 へのバージョンアップについて、パフォーマンスへの影響、Devin を使った実作業、rubocop.yml の対応など、具体的な取り組みをご紹介します。安定性を重視した今回のアップデートの背景や、今後の展望についても触れていきます。 2. バージョンアップによるパフォーマンスへの影響 今回の Ruby 3.4.2 へのアップデートでは、YJITについては以前のバージョンから引き続き有効であるものの、我々のアプリケーションでは目立った変化はありませんでした。 計測方法とアプリにつ

目次 目次 はじめに RBS について rbs-inline と Steep について RBS に出会ってからの Ruby への向き合い方 単一の型を返す意識がついた メソッドの戻り値の型だけを見て実装する機会が増えた Ruby で型を書くのも良いなと思った はじめに こちらは Timee Product Advent Calendar 2024 の24日目の記事です。 前日は @beryu の iOSの職能チームが存在しない組織で、WWDCハッカソンを企画・開催しました でした。 こんにちは。バックエンドエンジニアの @dak2 です。 タイミーではバックエンドの Ruby on Rails アプリケーションに型定義情報（RBS）を記述して運用しています。 もう少し具体的に話すと、rbs-inline を利用して RBS ファイルを生成し、Steep によって型検査しています。後半で詳し

こんにちは。エンジニアリング本部 プラットフォームエンジニアリングチームの徳富です。 この記事は、 Timee Product Advent Calendar 2024 の 20 日目として、EXPLAINを使用した実行計画の見方についてご紹介します。 背景 タイミーでは、会社の成長に伴い、パフォーマンスチューニングが喫緊に求められています。このような課題に対処するため、クエリのパフォーマンスチューニングにはEXPLAINを使用した実行計画の確認が非常に重要です。しかし、実行計画の解釈には社内でばらつきがありました。この問題を解消するために、実行計画の見方を社内でまとめ、共有することにしました。ただし、この情報を社内だけに留めておくのはもったいないと考え、テックブログを通じて広く公開することに決めました。 実行計画の基本的な見方 MySQLのEXPLAIN文は、SQLクエリがどのように実行

こちらは Timee Product Advent Calendar2024 の18日目の記事です。前日は @ryopeko による「RubyWorld Conference 2024に参加してきた」でした。 こんにちは。タイミーでバックエンドのテックリードをしている @euglena1215 です。 タイミーではモノリスな Ruby on Rails アプリケーションに一定の規律を設けるために Packwerk を導入しています。 A Packwerk Retrospective であったように、Packwerk はあくまでツールであり鋭いナイフです。ツールは使い手が意図を持って扱わないとそれに振り回されて怪我をしてしまいます。 この記事では、それぞれのチェッカーがどんな目的を達成するために使えるものなのかを自分なりに整理してまとめてみます。 Packwerk 自体はあくまで依存グラフを