大規模なマルチモジュール開発をSwiftPackageに移行して運用してみた

はじめまして、iOSエンジニアの阿久津 @sky_83325 です。

タイミーでは、機能ごとにEmbedded Frameworkに分割して開発するマルチモジュール開発に取り組んでいます。 現在では、本体AppやAppExtensionの他に7つの共通Framework、そして16個の機能Frameworkという規模になってきました。

今回は、そのマルチモジュール開発をEmbedded Frameworkではなく、Swift Packageを利用した方法に乗り換えてみたので、その成果や学びについて共有できればと思います。

続きを読む

タイミーでSLOを導入してみた

こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回は年末から仕込んでいたタイミーのSLOについてと、その時に得た学びを紹介したいと思います。

概略

結論としてタイミーのSLOで大事にしているのは以下の3つです。

  • プロダクトの緩やかな品質低下を検知できるものであること
  • プロダクトの健全性を大局的に把握できるものであること
  • 罰則はSLOを消費する行為に相反する行動を取ること

また、組織で新たなものをやる時は熱量/知識/経験のいずれか2つ以上が必要になることも学びとなりました。

  • 概略
  • SLO(Service Level Objective)とは
  • なぜSLOを作ったのか
    • SLO導入前の状態
    • SLOの役割
  • 導入のために行ったこと
  • タイミーで定義しているSLOについて
    • 利用チームについて
    • SLOでどの範囲を扱うかについて
    • 違反時について
    • SLOの見直しについて
  • SLOを導入してよかったこと
  • 失敗と学び
    • 小さく始める
    • やっていきするときに必要なもの
  • 終わりに
続きを読む

『ユニコーン企業のひみつ』を読んで。サービスの開発のように組織も計測しながら進むことが大切だと感じた

こんにちはタイミーCTOのkameikeです

昨日発売された、『ユニコーン企業のひみつ――Spotifyで学んだソフトウェアづくりと働き方』のレビューです。 書籍の発売前に抽選でもらえるキャンペーンに当選し、献本をいただきました。「謹呈」ののし紙がついた本をいただいたのは初めてでテンションが上がりました。

タイミーも現在の20名のプロダクト組織からスケールしていくフェーズに入ってきており、これはSpotifyが組織モデルを樹立しはじめたタイミングと同じであるため非常に参考になりました。

TL;DR

  • ユニコーン企業のひみつ』にはSpotifyの組織のマインドセット・ルールが書かれており、自律的なチームのヒントが多く含まれています
  • ユニコーン企業のひみつ』に書かれているような組織の実現は継続的な計測と改善がとても大切です
続きを読む

新規事業の決済機能としてStripeを導入する上で考えたこと全て

こんにちは、タイミーデリバリー開発チームの宮城です。
この記事はJP_Stripes Advent Calendar 2020の10日目の記事です。

タイミーデリバリーはデリバリーを頼みたい人が安い価格で注文でき、飲食店も安い利用料で注文を受けられるデリバリープラットフォームです。
その決済機能として今回はStripeを導入しました。
この記事では、決済基盤の技術選定/Stripeを活用したクレジットカード決済と各事業者への入金までの流れ/Railsでの具体的な実装内容 をそれぞれタイミーデリバリーでの活用事例として紹介します。

  • 導入にあたった背景
  • 決済基盤の技術選定基準
  • Stripeでできること
  • PCI DSSについて
  • 利用したStripeの機能
    • Custom Account
  • Stripe SDKを利用したRails/Swiftでの実装内容
    • PaymentIntent
    • Customer
    • Account
      • Connected Accountが決済を行えるようになるまで
    • 決済の全体像
    • DBに保存する情報とStripeで保持する情報の整合性担保
      • 仮登録フェーズ(Try)
      • 確定フェーズ(Confirm/Cancel)
    • stripe-ruby-mockを使ったTesting
    • 返金処理・経理業務
      • Stripeダッシュボードでの返金処理
      • API経由による返金処理
      • 返金のタイミング
      • 入金について
  • よかったこと
    • 決済に関するトラブルが非常に少なかった
    • ドキュメント、サポート、開発ツールが手厚い
  • 失敗したこと
    • 事業者に直接Stripeダッシュボードを見てもらった方が楽なケースが多かった
    • 事業者のStripeへの登録における実装がかなり重く、Expressで提供されているAccountLinkを使った方が良さそう
    • 今アカウントを選ぶとした場合の判断基準
  • 終わりに
続きを読む

増え続けるXaaSのユーザ管理をソフトウェア化していくお話

コーポレートエンジニア(兼いろいろ)をやっている @sion_cojp です。

本当はやり遂げた状態を発表したかったのですが、道のりも長かったため、今やっていこうとしてる内容を記事にしてみました。

この記事を見てタイミーのコーポレートエンジニアに興味を持っていただけたら幸いです。

  • TL;DR
  • 増え続けるXaaS、ユーザ管理、複雑化
  • 残されない手順書
  • 我々がやりたいこと
  • なぜterraform?
  • terraformで管理していくための課題
  • 課題を解決してみる
  • さらにソフトウェア化できそうなところ
  • APIがないXaaS
  • 最後に

TL;DR

  • XaaSユーザ管理を全てterraformにしていく
  • 名前とroleさえ設定してapplyすれば権限付与できる形式にしたい
続きを読む

ECSで通常時とスパイク時のオートスケールを運用する

こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回はタイミーで実践しているECSのオートスケール戦略についてお話ししようと思います。

TL;DR

  • タイミーではTarget Tracking ScalingとStep Scalingを組み合わせてオートスケールをしています
  • Target Tracking Scaling -> 通常のスケールアウト・スケールイン
  • Step Scaling -> スパイク時のスケールアウト
  • 2つを組み合わせることで、様々なリクエストに対し適切なリソースを用意しています
続きを読む

RailsのAPIサーバーのエラーレスポンスで例外に対応するエラーコードを返却する

はじめましてこんにちは。
夏が本気を出してきて最近麺類しか口にしていないサーバサイドエンジニアのかしまです。

この度APIにてHTTP Status Codeとは別に、例外に対応するエラーコードを返すよう奮闘したのでその知見を共有したいと思います。

やりたいこと

APIにて例外が発生した場合、以下の形式でレスポンスを返すようにします。

{
  "errors":
  [
     {
        "code":  "code1",
        "message": "message1",
     },
     {
        "code":  "code2",
        "message": "message2",
     },
  ]
}

Why?

今回追加したAPIは外部のアプリケーションとの連携に使うため、以下の要件を満たす必要がありました。

  • クライアントサイドがハンドリングしやすいような設計にする
  • エラーの識別子は不変であること

そのためエラーメッセージとは別に、コードを返すことにしました。

次の章から実際にどのように実装したかを紹介したいと思います。

続きを読む