はてなブックマーク

こんにちは、DevPFチームの菅原です。 現在、弊社のアプリケーション基盤（ECS on Fargate）では、コンテナログの収集・転送にFireLensを採用し、Datadog Logsへ集約しています。FireLensはタスク定義に数行記述するだけでログ基盤が整う非常に便利な機能です。一方で裏側では、Fluent Bitがサイドカーとして動作し、複雑なパイプラインを処理しています。 「ログなんて標準出力に出せば、あとは勝手に届くもの」 そう思われがちですが、実際にはアプリケーションコンテナからDatadog Logsのexplorerに表示されるまでには、いくつもの難所が存在します。今回は、ログがDatadogに到達するまでのアーキテクチャを紐解きながら、ログが「どこで」「なぜ」欠損するのかを解説します。 ログ転送のアーキテクチャ概要 まずは現在の構成のおさらいです。 基盤: AWS

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

こんにちは、タイミーでバックエンドのテックリードをしている新谷 (@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 自体はあくまで依存グラフを

こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 こちらは Timee Product Advent Calendar 2024 の10日目の記事です。 2024年8月に入社して、幸いにもチームメンバーにも恵まれて楽しく働いています。 個人的にキャッチアップがあまりできていなかった OpenTelemetry を題材にして実装をしてみたので、ここから得られた気づきや知見を共有したいと思います。 はじめに アプリケーションの可観測性（Observability）を担保する上で、APM(Application Performance Monitoring)は重要です。 現在、JaegerやPrometheusのような非商用のものから、DatadogやNew RelicやSplunkなど様々なAPMを利用できるツールが存在します。（本記事では

こちらは Timee Product Advent Calendar 2024 の9日目の記事です。前日は平岡の スクラムマスターが常に意識するべき重要なこと でした。 タイミーでテックリードをしている @euglena1215 です。 最近、Majestic Monolith と Citadel というアーキテクチャ・考え方を知ったのですが、あまり国内では認知度が高くないように感じたので紹介してみたいと思います。 自分が見つけた日本語での記事は モノリス亜種のアーキテクチャ(Modular MonolithとかMajestic MonolithとかCitadel Architectureとか) と Rails: AppSignalが採用する「シタデルアーキテクチャ」（翻訳）｜TechRacho by BPS株式会社 の2記事のみでした（※記事執筆時点）。 Majestic Monolit

この記事は Timee Advent Calendar 2024 シリーズ 1 の5日目の記事です。 はじめに こんにちは。タイミーの DRE チームの chanyou です。2024年の3月に DRE チームにジョインして、社内のデータ基盤を作って運用しています。 DuckDB を使ってデータ基盤で扱うデータの品質を保証し始めたので、その内容をご紹介します。 データ品質と完全性 タイミーのデータ基盤で重視しているデータ品質 タイミーでは、DMBOK を参考に以下のデータ品質を重視して設計や日々の運用を行っています。 特性 意味 完全性 データが欠損していないか 適時性 必要なときにすぐにデータを参照できるか 一意性 データが重複していないか 一貫性 型・タイムゾーン・表記揺れなど、値の書式や意味が統一されているか 今回は完全性にフォーカスします。 完全性が損なわれるタイミング 上記の通り

このエントリは「Timee Advent Calendar 2024」の12月2日分のエントリーです。 私は誰？ 2024年5月入社した山田といいます。 ニックネームは「やまけん」とみんなから呼ばれています。 本名より浸透しているので、社員の中には本名を知らない方も一定いる(らしいです)。 productpr.timee.co.jp 前職では、オンライン商談システムを展開するベルフェイスでCREチームのマネージャーをやっておりました。 note.com タイミーは現在、累計ワーカー900万人にご利用いただいているサービスとなっています。 これからも多くの方々にいいサービスを提供し続けられるよう、タイミーでは顧客満足度を技術的アプローチで高めていくためにCREチームを立ち上げることとなりました。 今日はタイミーでのCREの立ち上げから現在、そしてこれからについてお話します。 CREのはじまり

こんにちは、タイミーでデータサイエンティストとして働いている小栗です。 今回は、機械学習モデルの予測の不確実性を定量化する手法であるConformal Predictionについてご紹介します。 Conformal Predictionとは 機械学習モデルの予測値がどの程度信頼できるか知りたい場面は多いと思います。 医療診断のように誤った予測が重大な問題につながる状況でモデルを使用する場合、予測の不確実性を定量化してそれを元に判断できると嬉しいです。 Conformal Prediction（以下CP）はUncertainty Quantification（不確実性の定量化。以下UQ）のパラダイムの1つであり、モデルの予測値の集合/区間を統計的に厳密に作成します。 Conformal Predictionで生成される予測集合の例。出典: Angelopoulos, Bates (2022)

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 タイミーでは RBS の活用を推進する取り組みを少しずつ進めています。意図はこちら メンバーと雑談していたときに「steep check でコケたときにその名前で調べても全然ヒットしないので型周りのキャッチアップが難しい」という話を聞きました。 いくつかのエラー名でググってみたところ、 Ruby::ArgumentTypeMismatch や Ruby::NoMethod など有名なエラーはヒットしますがほとんどのエラーはヒットせず、ヒットするのは Steep リポジトリの該当実装のみでした。 これでは確かにキャッチアップは難しいだろうと感じたので、Steep のエラーリファレンスを作ってみました。ググってヒットするのが目的なのでテックブログとして公開してインデックスされることを期待します。 各エラーの説

エンジニアリング本部 プラットフォームエンジニアリング1G 橋本です。我々のグループでは業務の柱の一つとして、クラウドインフラの構築・運用を行っています。その中でAmazon Aurora MySQL（以下、AuroraもしくはAurora MySQL）のアップグレードがビジネスインパクトが大きい作業となりました。本記事はAurora MySQLアップグレード方法の検討について記述した投稿になります。 この記事のまとめ 前提情報や課題感について Blue/Green Deploymentsによるアップグレードとは もしもの場合はロールバックしたい 検討したロールバック手法 DMS方式 リストア方式 逆レプリ方式（没案） 困った。どうしよう？ タイムリーな機能を教えてもらえた？ SwitchOver時に静止断面を教えてくれる 逆レプリ（新案）はどうなるのか？ いままでの方式案との比較 まとめ

こんにちは、タイミーのデータアナリティクス部でデータアナリストをしている夏目です。普段は主にタイミーのプロダクトに関する分析業務に従事しています。 本日はタイミーにおいて、効果検証設計を施策前に正しく行える仕組みづくりと効果検証設計・結果を一元的に管理できるデータベースについてご紹介します。 解決したかった課題 タイミーでは、プロダクト、マーケティング、営業組織などで様々な施策が行われています。しかしながら、それらの施策の結果を判断する効果検証には課題も多く存在しています。今回は以下の２つの課題にフォーカスしてブログを書きます。 効果検証設計が事前になされていない施策があった 効果検証設計や検証結果がバラバラに保管され、会社として知見が溜まっていなかった まず１つ目の「効果検証設計が事前になされていない施策があった」に関してです。タイミーではアナリストの数も限られており、事前に全ての施策に

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 この記事は先日公開した「前編：YARD から rbs-inline に移行しました」の後編となっています。前編では rbs-inline の紹介、移行の目的などをまとめています。前編を読んでいない方はぜひ読んでみてください。 tech.timee.co.jp 後編では実際の移行の流れや詰まったポイント、今後の展望について紹介します。 移行の流れ 1. 型をやっていくことを表明する 2. rbs-inline のセットアップを行う 3. YARD から rbs-inline への移行を進める 4. 後片付け sord gem の削除 rbs subtract をやめる 今後の展望 型検査を通す リアルタイムな実装へのフィードバック まとめ 移行の流れ YARD が日常的に書かれている状況から YARD がほ

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 タイミーのバックエンドはモノリスの Rails を中心に構成されています。そのモノリスな Rails に書かれていた YARD を rbs-inline に一通り移行した事例を紹介します。 前編では、rbs-inline の紹介と rbs-inline への移行理由について触れ、後編では実際の移行の流れや詰まったポイント、今後の展望について触れる予定です。 rbs-inline とは RBS 活用推進の背景 移行理由 1. YARD(sord) よりも rbs-inline の方が表現力が高い 2. YARD は書いていたが yardoc は使っていなかった 3. rbs-inline が今後言語標準の機能になっていく rbs-inline とは まずは rbs-inline について簡単に紹介します。

読んで欲しいと思っている人 POやステークホルダーと品質について共通言語や目標が欲しい開発者 開発者と品質について共通言語や目標が欲しいPO スクラムで品質について困っている人 読むとわかること 完成の定義（Definition of Done）とはどんなものか スクラムと非機能的な品質の関係性 タイミーのWorkingRelationsSquadでどんな完成の定義を作り、活用していきたいと思っているか 完成の定義（Definition of Done）とは インクリメントが常に守るべき状態のことです。スクラムガイド1では以下のように説明されています。 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。 つまり完成の定義を満たしていない成果物は、いかに優れた機能であっ

タイミー QA Enabling Teamのyajiriです。 去る6月28日〜29日の2日間、ファインディ様主催の「開発生産性カンファレンス2024」に参加してきました。 （タイミーには世界中で開催されるすべての技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、今回もこれを利用して新潟からはるばる参加してきました。） productpr.timee.co.jp タイミーでは弊社VPoE(VP of ええやん Engineering)の赤澤の登壇でもご紹介した通り、チームトポロジーを組織に適用し、プロダクト組織の強化と改善にチャレンジしています。 speakerdeck.com この登壇でも紹介されておりますが、私自身もイネイブリングチームの一員として、プロダクト組織全体のQA（品質保証）ケイパビリティの向上や、障害予防プロセスの改善に取り組んでいます。 開

株式会社タイミーのkatsumiです！ dbtのバージョン1.8以上を利用することで、unit testsが利用可能になります。今までもSingular テスト（単一テスト）やGeneric テスト（汎用テスト）は可能でしたが、テストデータを利用した単体テストも行うことができます。 導入準備 dbt-coreの場合 dbt v1.8 以上を利用してください。 dbt-cloudの場合 2024/06/12時点では dbt「Keep on latest version」を選択することで利用できます。 弊社ではunit-test用の環境のみlatest versionを利用しています。 Unit Testの基本 # run data and unit tests dbt test # run only data tests dbt test --select test_type:data #

※Timeeのカレンダー | Advent Calendar 2023 - Qiitaの12月13日分の記事です。 はじめに こんにちは okodoooooonです dbtユーザーの皆さん。dbtモデルのbuild、どうやって分割して実行してますか？ 何かしらの方針に従って分割をすることなく、毎回全件ビルドをするような運用方針だと使い勝手が悪かったりするんじゃないかなあと思います。 現在進行中のdbtのもろもろの環境をいい感じにするプロジェクトの中で、Jobの分割実行について考える機会があったので、現状考えている設計と思考を公開します！（弊社は一般的なレイヤー設計に従っている方だと思うのでJob構成の参考にしやすいと思います） この辺をテーマに語られていることってあんまりないなあと思ったので、ファーストペンギンとして衆目に晒すことで、いい感じのフィードバックをもらえたらなーと思ってます。