Timee Product Team Blog

タイミー開発者ブログ

バッチ処理の改善 〜冪等性の設計導入〜

前編(トランザクション範囲の最小化)へ

はじめに

こんにちは。タイミーのバックエンドエンジニア中野です。

前編では締めのバッチ処理におけるトランザクションの範囲を最小化した技術的改善をご紹介しました。トランザクションの範囲をバッチ処理全体から最小限の範囲に変更したことにより、バッチ処理が失敗した場合に請求レコードの処理が途中まで完了している状態が発生するようになりました。後編では、処理対象の請求レコードに対し状態を持たせることでバッチ処理全体での冪等性を担保し、バッチ処理が途中で失敗した場合でも安全に処理を再開できるようにした取り組みをご紹介します。

  • はじめに
  • 締めのバッチ処理とは
  • 現状の課題認識
  • 実施した施策
    • 冪等性とは
    • 冪等性を実現する方法
    • バッチ処理への適用
  • 達成できたこと
  • 今後の課題
  • まとめ
続きを読む

バッチ処理の改善〜トランザクション範囲の最小化〜

後編(冪等性の設計導入)へ

はじめに

こんにちは。タイミーのバックエンドエンジニアの中野です。よくGopherくんに似てると言われます。

本記事では月次で実行している「締め」のバッチ処理に関する一連の技術的改善について掲載します。弊社のプロダクト「タイミー」は著しい事業成長に伴いデータ量が急増してきています。そこで今回はデータ量の急増を背景とした中長期的なバッチ処理の設計改善にどのように取り組んできたのかをご紹介したいと思います。バッチ処理に関する技術的改善の記事は前編・後編の2部構成をとっています。前編はバッチ処理におけるトランザクションの改善をテーマに、後編ではバッチ処理に冪等性の設計を導入したことをご紹介したいと思います。
今回は前編のトランザクションの改善をテーマにご紹介します。すでに本番稼働しているアプリケーションにおいてトランザクションの範囲が大きい場合にどのような問題が発生したのか、そしてどう解決していったのかを中心に取り上げます。

読み手としては、今後データ量の急激な増加が見込まれるプロダクト開発の中長期的な設計・運用を模索している方を想定しています。また読み手に該当しない場合でも、現在タイミーがどのような事業を推進しているのか興味を持ってもらえるように記載しましたので是非最後までお付き合いください。

続きを読む

ユーザーインタビュー参加コストを極小化する仕組み

この記事はタイミーのPMM(Product Marketing Manager)のishinabeが担当します。

PMM??と思った方もいるかもしれないので軽くどんなミッションを持っているのかを説明しておくと、デプス調査や定量分析などなどを絡めて顧客課題やジョブの発見から、その深さ・ボリュームの推定、リリースする機能のマーケットイン(機能に価値を感じてもらえる顧客に機能を認知してもらい使ってもらうこと)あたりを主な任務としてIssue度が高いものから解決しようと動いています。

また、今回の記事のテーマのように、デプス含めた顧客理解を組織にインストールすることも重要なミッションとして捉えています。

※前提、世の中的にもまだ役割がかっちりと定まっている訳ではないので、私も関連チームと会話しつつ模索しながら動いている段階です(この記事の話はどちらかというと世に言うUXリサーチャーっぽい動きかも知れない)。

さて、本題の「ユーザーインタビュー参加コストを極小化する仕組み」お話しです。
なお、以降「ユーザー」→「ワーカー」と表記します。タイミーのサービスのユーザーは、お仕事内容を掲載して働く人を募集する「クライアント」と、お仕事に申し込んで働く「ワーカー」に大別されるためです。

  • 何をやったか
    • やりたいという意思表示をしたらあとは当日参加するだけ
    • 裏側で処理されていること
    • インタビュー参加のサポート
  • なぜやったか
  • 取り組みへのフィードバックなど
    • 今後の展望
  • 最後に自己紹介とおさそい
続きを読む

Notion API を使った機能開発 〜最小の実装で作る要望回収システム〜

はじめに

こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。 タイミーでは toB 向け管理画面を作成しています。

半年ほど前、タイミーでは顧客からのサービスへの要望を集め、管理するシステム(以下、要望回収システム)を作りました。 顧客の課題から新しい機能について考え、顧客により価値のあるものを届けるための施策です。

システムの実装には Notion という SaaS を活用しました。 最小限の実装で良い機能・良い運用が作れたと思っています。

この記事では、要望回収システムの実装に取り組んだ経緯から、実際の運用の例まで紹介します。 同じように顧客の要望回収を行いたい方はもちろん、SaaS を使ったミニマルな機能開発の参考になれば幸いです。

  • はじめに
  • Notion
  • 従来の回収システム
    • 課題
  • 解決したい課題
  • Notion API を用いた課題解決
    • 制約
  • データベースの構成
  • 回収システムの Notion の構築
  • 運用
  • まとめ
続きを読む

モバイルアプリ開発におけるメトリクスを改善することで、SLO違反の予兆や改善の傾向を認知しやすくした話

はじめに

はじめまして、Androidエンジニアのmurata(@orerus)です。

アイラ系ウイスキーを愛していますが、肝臓が弱まってきた為最近は専ら0.5%ハイボールを愛飲しています。

本記事では、タイミーのモバイルアプリ開発におけるSLO(サービスレベル目標)を設けているメトリクスのちょっとした改善事例について紹介します。

SLOとは何かといった話やタイミーで運用しているSLOについてはこちらの記事にて詳しく紹介していますので是非ご覧ください!

本記事の概略

タイミーのワーカーチームでは、モバイルアプリ開発における指標の一つであるクラッシュフリーレートをSLI(サービスレベル指標)としてSLOの運用を行っています。

しかし、長く運用する中で、SLO運用に期待されている「当たり前品質と攻めたリリースのバランスを取る」「当たり前品質の低下をいち早く検知する」「適切なタイミングでプロダクト品質への改善圧をかける」といった役割が果たされていないと感じられるケースが度々発生していました。

そこで、モバイルアプリ開発メンバーが普段観測しているクラッシュフリーレートのメトリクスを改善することにより問題を解消した事例について紹介します。

目次

  • はじめに
  • 本記事の概略
  • 目次
  • 現状と課題
  • 行った改善策
  • 結果変わったこと
  • 最後に
  • APPENDIX
続きを読む

タイミーのAndroidアプリ開発で採用しているモジュール分割の取り組みについて

はじめに

はじめまして、Androidエンジニアのsyam(@arus4869)です。

普段は愛知県からフルリモートで勤務していますが、最近は褪せ人として荒野を駆けています。

本記事の概略

本記事では、タイミーのAndroidプロジェクトで挑戦しているモジュール分割の取り組みについて紹介します。

また内容の理解を促すため、マルチモジュールについても軽くおさらいします。

本記事では、以下の方を読者として想定しています。

  • 他社のモジュール分割の手法に興味がある方
  • マルチモジュールなプロジェクトに挑戦してみたい方
  • はじめに
  • 本記事の概略
  • 現状のタイミーとアプリについて
  • 課題
  • モジュール分割とは
    • 「マルチモジュール」なプロジェクトの例
    • 分割のステップ
  • モジュール分割のメリット
  • モジュール分割のデメリット
  • 現在のアーキテクチャ
    • analytics
    • pubsub
    • component
    • style
    • core
    • repository
    • repository-impl
  • Feature Moduleによる機能分割について
  • FeatureModuleにおける画面遷移について考えていること
  • おわりに
続きを読む

マイクロサービスからモノリシックへ。チャットサーバ移行の道のり

はじめに

はじめまして、バックエンドエンジニアのぽこひで (@pokohide) です。

最近の日課はゲーム実況者「兄者弟者」の「DYING LIGHT 2 STAY HUMAN」と「エルデンリング」を見る事です。

本記事ではタイミーで長年使われていた、マイクロサービスとして切り出されたチャットサーバ(以降、旧チャットサーバと呼びます)をタイミーの中核を担うモノリシックなRuby on Railsサービス(以降、タイミー本体と呼びます)に移行した話です。

今回は移行した経緯、気にした点などを紹介します。

対象にしている読者は以下の方々です。

  • レガシーなシステムと向き合っている人
  • 無人化システム ※1 に疲弊している人

※1 : 無人化システムとは この記事 に出てくる造語で「誰も詳細は知らないが、なぜか動いているシステム」を意味する

  • はじめに
    • チャット機能とは
    • 旧チャットサーバとは
  • なぜやるのか
  • やること・やらないこと
    • やること
    • やらないこと
  • 移行計画の検討
    • 移行計画まとめ
  • 結果
  • 最後に
続きを読む