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は外部のアプリケーションとの連携に使うため、以下の要件を満たす必要がありました。

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

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

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

続きを読む

オフィスのネットワーク構築についてのお話

SREとコーポレートエンジニアをやっている @sion_cojp です。

今回は新オフィスのネットワーク構築を実施したので、こちらについてお話します。

私自身、学生時代の研究や、10年前にデータセンターのネットワーク構築しか経験がないため、所々おかしな点があるかもしれませんが、ご了承ください。

また今回相談に乗ってくださった @kajinari さんに感謝の意を表します。

TL;DR

  • 旧オフィスはとても不安定なネットワークでしたが
  • coltの回線とmerakiのネットワーク機器で
  • 快適なネットワークができました
  • 予算問題で達成できなかったこと: L3/L2機器 + ネットワーク回線の冗長化
続きを読む

Rails + RSpec + OpenAPI3 + Committeeでスキーマ駆動開発を運用するTips

こんにちは、タイミーデリバリー開発チームの宮城です。
今回は弊社のOpenAPI3ベースのスキーマ駆動開発の運用方法を紹介します。

TL;DR

  • 技術スタックは OpenAPI3, Swagger UI, Committee, ActiveModelSerializers
  • Committeeを利用してOpenAPI準拠のRequest Specを行う
  • OpenAPI3のrequiredキーワードに注意する

背景

タイミーデリバリーでは、RailsによるAPIサーバーと、Web管理画面としてVue.jsによるSPA、ユーザー向けiOSアプリとしてSwiftを採用しています。
1つのモノリスRailsで利用者別にネームスペースを区切り、それぞれエンドポイントを提供しています。
サーバーサイドとクライアントサイドを分離し並行して開発を進めるためにスキーマ駆動開発を導入しました。スキーマ駆動開発の詳しい説明やメリットについては既に多くの記事が存在するため、ここでは参考にさせていただいた記事の紹介までとさせていただきます。

RubyKaigi 2019でOpenAPI 3について登壇しました - おおたの物置

スキーマファースト開発のススメ - onk.ninja

スキーマ駆動開発のススメ - Studyplus Engineering Blog

この記事では、実際にスキーマ駆動開発を開発フローに導入する際のTipsを記したいと思います。

続きを読む

RedashをFargate, Datadog, Terraformで構築/運用する

こんにちは、タイミーSREチームの宮城です。
今回は弊社がRedashをFargateで構築/運用している話を紹介します。

背景

タイミーでは、CSやセールスのKPI策定から毎月の事業数値に至るまで、Redashが様々な用途で活用されています。
Fargateで構築する以前はEC2上のdocker-composeで運用されていましたが、以下の課題がありました。

  • オートスケールできないため、クエリが詰まってCPUが100%になってサービスが停止する。
    • その度slack上から再起動していた
  • セットアップしたエンジニアが退社しており、インフラ構成図やノウハウの共有、IaCによる管理ができていない。
  • クエリやダッシュボードなどのデータの定期的なバックアップができていない。
  • v7系からv8系へのアップデートがしたいが、アップデートによる影響範囲がわからず恐怖感がある。
  • 事業に大きく関わるサービスなのにも関わらず、モニタリングやアラートができていない。

上記をFargateに移行することで解決することができました。

移行後のアーキテクチャ

f:id:MH4GF:20200418180434p:plain

Redashで利用するミドルウェアに関しては下記コンポーネントを使い、全てをterraformで管理しています。
- PostgreSQL -> RDS
- Redis -> ElastiCache

それぞれの構成の紹介

ここからは、それぞれの構成をTerraformのソースコードやタスク定義のJSONなどを交えつつ説明していきます。

続きを読む