Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話

こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。

初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。

見直しのきっかけ

トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。

製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。

入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいちから見直すことにしました。

当時の問題点

当時、トレタのテスト仕様書は Excel で管理されていました。 Excel は閲覧性が高くテスト仕様書の管理ツールとしても一般的ですが、テストケース管理という意味では不便を感じることがあります。たとえば、こんなところです。

• そもそも手元に Office が無いとテストケースの閲覧・メンテナンスができない
• バイナリファイルなので git などでバージョン管理しにくい
• 複数人で共同編集しにくい
• テストケースのレビューがしにくい
• テストケースの変更履歴や変更の経緯を残しにくい

今後テストケース数も関わる人も増えていく予定だったので、メンテナンスしやすく継続しやすい管理方法を検討することにしました。

Excel から Markdown へ

もろもろ検討した結果、Excel ではなく Markdown (GFM) 形式で記述して、プロダクトのコードと同じように GitHub 上で管理してみることにしました。そうすることで、

• テキストエディタでどこでも気軽に編集できる
• テキストファイルなので GitHub でバージョン管理・変更管理がしやすい
• 複数人で同じファイルを編集しても git がよしなにマージしてくれる
• Pull Request を使ってテストケースのレビューを行える
• プロダクトの Issue/PR とテストケース変更の Issue/PR を紐付けておくことで、テストケース変更の経緯を後から git blame で追いかけることができる

といった効果が狙えます。記述ルールは、GitHub のプレビュー上でもそれっぽく見えるように下記のようにしてみました。

記述ルール

• 大項目(画面名) : h2
• 中項目(機能名) : h3
• テスト内容: li
• 確認内容 : checkbox

書き方の例

## ログイン画面

### ログイン機能
- 正しいメールアドレスとパスワードを入力してログインボタンをタップする
  - [ ] ホーム画面に遷移する

GitHub での表示

テスト実行時は Spreadsheet で

テストケースを管理する際は Markdown の方が扱いやすいですが、いざテストを実行する時は Excel 的な形式の方が一覧して見やすく、テスト時に気付いたことをメモとして残したりもできて、何かと便利なことがあります。そこで、Markdown 形式のテストケースを Google Spreadsheet に変換するための仕組みも準備しました。

具体的には、テストケースを GitHub に push したときに CircleCI で構文をチェックしつつ OK だったら、 google_drive gem で Google Spreadsheet に展開するようにしています。こんな流れです。

デプロイの流れ

Spreadsheet 上の表示

たかがテストケース管理だけのためには少々大げさかもしれませんが、これによってひとつのテストケースを Markdown 形式でも Spreadsheet 形式でも参照できるようになり、テストの編集時と実行時とで形式を使い分けることができるようになりました。

さいごに

今回は、テストケース管理について紹介しました。今後また、テストプロセス、テスト自動化への取り組み、CIまわりの取り組みなどこの場でお話できればと思っています。

そしてお約束。トレタは iPad アプリを Swift に移行しつつ、Testability の高い設計・コードに書き換えている真っ只中にあります。iOS エンジニア絶賛募集していますので、ご興味があれば一度オフィスに遊びにきてみてください。

EngineyardからAWSに移設してAuroraの運用を開始した

どうも佐野です。トレタのインフラはEngineyardでワオワオやってたんですが、あの、なんていうのAurora？それを使いたかったわけです。 さて、私が書いた前々回の記事にて、「コア機能のAWS化」を今後のTODOとして挙げていましたが、5/9にEngineyardからAWSへの移設が完了していました。EngineyardはRailsやnodejsなどのWEB-DB環境を簡単に構築できるPaaSです。Herokuとの違いはサーバにsshしたり、chefを利用してFluentdなどのミドルウェアを入れたり、既存のコンフィグレーションをカスタマイズしたりすることができる点が挙げられます。比較的自由度の高いPaaSと言えるでしょう。トレタでは創業〜先月までお世話になりました。 今回は移設とAuroraの運用に関するTipsの紹介になります。なお、本記事に示す設計・運用方針はAWSのソリューションアーキテクトの支援を得て決定したものではなく、私の見解で決定したものなのでご了承ください。ベストプラクティスではないかもしれません。

以下、目次になります。

1. 移設
2. Auroraのコンフィグレーション
3. 基本、マスターのみを使う
4. スロークエリの検出
5. フェイルオーバするとき
6. スケールアップするとき
7. Auroraのメンテナンスをするとき
8. リストアするとき
9. MySQL on EC2からレプリケーションを行う場合
10. 失敗したこと

1. 移設

運用エンジニアを長らくやっていると移設は慣れっこなのですが、弊社エンジニアに移設経験者が私しかいませんでした。MTGで「なるほどー」という空気になったので書いてみます。システムの移設をやったことがない、これからやる、という方がいらっしゃいましたら参考にしてみてください。 移設は往々にしてデータをどのようにして新環境に移すか？というのが技術的な課題になります。トレタの場合、MySQL, Redisといったレプリケーション可能なよく知られたデータストアを使っていたので、技術的な難しさはほとんどなく、どちらかというと社外を含む関係各所へのメンテナンスの日程の調整の方が骨が折れました。このあたりはセールスチームなどの協力を得て今回はスムースに調整を進めることができました。 技術的な移設手順は下記の通り。

1.1. これを

Engineyardで稼働している状態です。AWSに新環境を作っておきます。

1.2.こうして

データストアは新環境からレプリケーションを張っておきます。Engineyardはsshポートがグローバルに開放されているので、sshトンネルを張ってトンネル経由でレプリケーションを行いました(Engineyardのサポートに連絡すれば3306ポートをIP制限掛けてグローバルに開放してくれたかもしれない)。またsshプロセスはmonitで監視し、もし落ちた際は自動再起動するようにしておきます。Redisについても同様、sshトンネル経由で6379ポートに接続してデータの同期を行います。 Auroraから外部のMySQLにレプリケーションを行う場合(Auroraがスレーブ、MySQLがマスタ)は、 call mysql.rds_set_external_master のようなストアドで行います。このあたりはRDSのマニュアルを参照してください。で、今回はEngineyardのMySQLにsshトンネル経由でレプリケーションを行う必要があるため、AWS上に踏み台のMySQLを用意し、カスケード接続でAuroraにデータを同期させます。図の通り、Engineyard MySQL <- (sshトンネル) <- EC2 MySQL <-(ストアド利用) <- Auroraというレプリケーションチェーンになります。

1.3. こうやって

これはメンテナンス時間中に行います。まずシステムをメンテナンス状態にします。そしてデータストアのレプリケーション遅延がゼロになっていることを確認して、ウェブアプリケーションのデータストアの接続先が新環境に向くようにします。終わったらメンテナンスを解除します。トレタではメンテナンス時間は1時間設けました(実作業時間は確認を含めて30分程度でした)。 蛇足ですが、Auroraなどのデータストアはパブリックアクセス可能な状態にし、旧環境であるEngineyardのAppサーバからのアクセスを許可しておく必要があります。

1.4. こう

あとは日中帯に落ち着いて新環境にデプロイを行い、DNSを新環境に向けて終わりです。

2. Auroraのコンフィグレーション

長らくMySQL運用おじさんをやっていた身としてはやはりコンフィグが気になります。私が気にした箇所についていくつか抜粋します。総括すると、大抵のものはデフォルトで良さそうな印象を受けました。

クラスタパラメータグループ

* 文字コード
character_set_client = utf8
character_set_server = utf8
character_set_connection = utf8
character_set_database = utf8
character_set_results  = utf8
skip-character-set-client-handshake = 1
* バイナリログ
binlog_format = MIXED
log_slave_updates = 1(デフォルト)
sync_bin_log = 1(デフォルト)
* InnoDB
innodb_commit_concurrency = 0(デフォルト)
innodb_purge_threads = 1(デフォルト)
innodb_file_per_table = 1(デフォルト)
innodb_flush_log_at_trx_commit = 1(デフォルト)
innodb_support_xa = ON(デフォルト)

文字コード周りとバイナリログの有効化を設定してあります。移設の段階でカスケード接続させるのでlog_slave_updatesは1にします。sync_bin_logは1で良いでしょう。またバイナリログの保持期間を設定する expire_logs_days は無く、 call mysql.rds_set_configuration('binlog retention hours', 24); などとしてストアドでバイナリログの保持期間を設定する必要があります。InnoDB関連でいくつか気になるものがありますが、デフォルトで納得できる値になっていました。

DBパラメータグループ

* 接続周り
max_connections = 自動計算(デフォルト)
thread_cache_size = 自動計算(デフォルト)
max_allowed_packet = 134217728(128M)
* スローログ
slow_query_log = 1
long_query_time = 2
log_queries_not_using_indexes = 1
log_output = TABLE(デフォルト)
* 各種バッファ
tmp_table_size = 67108864(64M)
max_heap_table_size = 67108864(64M)
sort_buffer_size = 8388608(8M)
join_buffer_size = 131072(128K)
innodb_sort_buffer_size = 1M(デフォルト)
innodb_log_buffer_size = 8M(デフォルト)
* InnoDB
innodb_buffer_pool_size = 自動計算(デフォルト)
innodb_flush_method = O_DIRECT(デフォルト)
innodb_buffer_pool_dump_at_shutdown = 1(デフォルト)
innodb_buffer_pool_load_at_startup = 1(デフォルト)
* 分離レベル
tx_isolation = REPEATABLE-READ(デフォルト)
* クエリキャッシュ
query_cache_size = 自動計算(デフォルト)
query_cache_type = 1(デフォルト)

接続周りの設定、スローログ、各種バッファ、InnoDB関連、トランザクション分離レベル、クエリキャッシュあたりをケアしました。

• 接続周り

thread_cache_size、max_connectionsが自動計算されるようになっていて、計算後の値も適切だったのでAuroraの自動計算に任せました。max_allowed_packetは自分のMySQLの秘伝のタレの値をそのまま転用。

• スローログ

スローログについては閾値を2秒とします。RDSの場合、log_outputはTABLEとなり、これはmysql.slow_logにログが蓄積されることを意味します。

• 各種バッファ

バッファの数値はちょいちょいいじりました。とはいえこれらの数値の根拠はなくて、私の経験的にデフォルトではちょっと小さいのではないか？と思ってこのような数値にしてあります。

• InnoDB

クラスタパラメータグループだけでなくDBパラメータグループにもInnoDB周りの設定があります。性能面において最も重要な設定の一つであるinnodb_buffer_pool_sizeはこちらにあり、これもAuroraによって自動計算されるようになっています。innodb_flush_methodもO_DIRECTになっており、これらは適切な値だったのでとくにいじりませんでした。

• トランザクション分離レベル

確認したところ、tx_isolation = REPEATABLE-READがデフォルトで設定されていたので特に変更せず。

• クエリキャッシュ

デフォルトで有効になっており、キャッシュサイズは自動計算されていました。実はこれが個人的にちょっと悩ましくて、私の経験上、過去にクエリキャッシュが効果を発揮したことはあまりなかったです(根拠のあるデータを出すことができずすみませんが...)。インデックスが効いていれば十分高速ですし。無効にしたいところだが、Auroraの推奨？と判断して特に変更せずこのままとしました。

3. 基本、マスターのみを使う

現状のトレタのトラフィックでは1DBで十分です。1DBでの運用を行います。(スレーブは深夜のバッチ処理で使うようにしてありますが)基本的にスレーブは昇格用のスタンバイです。

4. スロークエリの検出

上の方に書いた通り log_output = TABLE のためスロークエリは mysql.slow_log テーブルに出力されるようになります。監視用に立てたインスタンスから次のようなクエリを定期的に投げて、スロークエリを検出しています。

select * from mysql.slow_log where start_time > '%s' order by start_time

トレタでは次の様にしてSQL警察がslackに通知するようにしています。

5. フェイルオーバするとき

フェイルオーバーボタンをポチります。数十秒〜1分程度です。

6. スケールアップするとき

インスタンスサイズの大きいreader*1を優先度tier-0(優先度-0)*2で作成し、フェイルオーバーを行います。

7. Auroraのメンテナンスをするとき

Auroraも他のRDSがサポートしているエンジン同様、Aurora自体のメンテナンス(OSアップグレード、バージョンアップetc)が必要なケースがあります。トレタではAuroraのメンテナンスはフェイルオーバーで行う方針です。つまり先にスレーブをupgradeしてそれをマスタに昇格させます。このリンクのようにAuroraのメンテナンス時はフェイルオーバーじゃなくて再起動の方が早い、つまり無下に「upgrade now」を実行してもよいと言及されている場合もありますが、私が実験した結果では、upgrade nowの停止時間は短い時は短いが遅長い時もある、フェイルオーバは安定して1分程度の停止時間、という結果になったので停止時間が安定している方を採択する方針です。upgrade nowの停止時間はAuroraのメンテナンスの内容、インスタンスサイズ、実施時の負荷などに依存するのかもしれません。

• db.r3.largeをupgrade now: 16秒停止
• db.r3.largeをフェイルオーバ: 60秒停止
• db.r3.xlargeをupgrade now: 1分59秒停止
• db.r3.xlargeをフェイルオーバ: 55秒停止

なお、ここでいう停止時間とは、インターネット経由でシステムのエンドポイントを叩き、オフラインになった時間を計測しています。なのでAurora自体の停止時間に加えて、ヘルスチェックなどで切り離されてしまった時間から復活する時間も含まれています。

8. リストアするとき

任意の時刻でのpoint-in-timeリカバリが可能です。もし時刻ではなく、たとえばオペミスでdrop tableしちゃってdrop tableの直前まで戻したい場合などは、バイナリログを活用することになるでしょう。

9. MySQL on EC2からレプリケーションを行う場合

AuroraをマスタとしてEC2など外部のMySQLをスレーブにするパターンです。移設のときと逆ですね。こちらについてはいつもどおりAuroraにレプリ用のユーザを作成して 外部のMySQLから change master すればよいです。

10. 失敗したこと

リザーブドインスタンスにし忘れた...:(；ﾞﾟ'ωﾟ'): うーむ...。RDSってあとからリザーブドにできなかったよね...？？？ (追記)各所よりあとからリザーブにできると教えていただきました

おわり

*1:readerというのはいわゆるスレーブ。Aurora用語かな？マスタはwriterと呼ぶ。

*2:昇格の優先度です。後ろの数字が若いものが優先的に昇格されます。

Shoryukenでつくるバッチ処理基盤

トレタのAPI開発を担当している芹沢です。

トレタでは、長時間かかるバッチ処理を複数台のサーバ上で処理させて短時間で処理できるバッチ処理基盤をAWS上で構築しました。この仕組みについて説明します。

目的

短期的には以下の課題を解決するため、長期的には似たような要件が再度発生した時に、同じ手法で解決できることを目的に作りました。

• 非同期でDBをデータソースとしたデータを加工してCSVファイルとして出力してS3にputしたい
  • データソースはDBに入っているリアルタイムのデータであることが求められる
  • CSVファイルの作成は決められた時間内に完了する必要がある
  • 対象となるデータソースの量は日々増加し続けるが、常に決められた時間内にCSV作成が完了している必要がある

難点

今回の要件で技術的に難しい点は以下の２点です。

DBを直接参照しながら大量のデータを処理する

例えば、データソースとしてDBからHDFSやRedshiftに同期されたデータを使えるのならば、AWS EMRなどのサービスを活用することで大量のデータを処理することは比較的容易です。しかし、今回の要件は、更新頻度が高いデータソースをできるだけリアルタイムに近い状態で取得してCSVを作成する必要がありました。

一定のスループットを担保し続ける

今回の要件上、1回のCSV処理作成にかかる時間を15分以内に抑える必要がありました。inputとなるデータ量が常に一定であれば一度15分以内に終わるように構築すれば、あとはそれを延々と動かし続ければ良いのですが、データ量が増加し続けるという事情があるため、データ量が増えても一定のスループットを担保し続ける仕組みを用意する必要がありました。

バッチ処理専用の環境を作ることにしました

これらの課題を解決するために以下の様な基盤を構築し、その上にデータ処理用のバッチを実装しました。

処理の流れは図の通りです。

バッチの実装について

いわゆるJob Queueですが、以下２つのJobが介在します。前者はSidekiq、後者はShoryukenを使って実装されています。

IDをグルーピングしてCSV作成Jobを作るJob

1. sidekiq-cronによって15分に1回起動します
2. 処理対象のレコードのIDを取得し、100IDずつにグルーピングします
3. グルーピングしたIDを引数としたCSV作成Jobを処理対象のレコード数分だけ作成します

CSVを作成するJob

1. Jobに含まれるIDを元にCSVを作成します
2. 作成したCSVをS3にpushします

1st release時点では、処理対象のデータのIDが800個ほどあったので、１回の処理につき8個のCSV作成Jobが生成され、8個のShoryuken workerが8並列で処理します。

個々のCSV作成Jobの処理時間は概ね10分〜11分に収まっているので、結果的に15分以内に処理を完了させるという目標を達成できました。処理対象のIDが増加してもShoryuken orkerの数を増やすことでスループットを増加させることが可能になっており、スケールアウトしやすい構造になっています。

Shoryukenについて

あまり日本語の記事を見かけなかったので簡単に紹介します。

Sidekiqとほぼ同じような使い方で使えるworker gemです。Sidekiqと異なる点として、Queue storeにAWS SQSを使います。元々トレタでは非同期処理にはSidekiq + redisを使っていましたが、今回のようにJobの数がスケールしていくことが想定されるケースにおいてはQueueのサイズや数に融通が効くSQSの方が適しているという判断の元、SQSを使うためにShoryukenを採用しました。

Tips: 各Jobのロギングについて

ShoryukenにはJobの実行時に前処理・後処理を挟むなどの目的に使えるMiddleware機構があります。 今回はJob実行時のパフォーマンス計測とエラー時の原因調査のために各Jobのログをfluentdで拾ってBigQueryに入れておきたかったので、以下のようなMiddlewareを自作してログをテキストファイルで残すようにしました。

module Shoryuken
  module Middleware
    module CustomMiddleware
      module Server
        class ProcessingTimeMeasure
          def call(worker, queue, sqs_msg, body)
            shoryuken_log_path = Rails.root.join('log', 'shoryuken_worker.log')
            @logger = ::Logger.new(shoryuken_log_path)
            @logger.formatter = proc do |_, _, _, message|
              message.to_json + "\n"
            end

            @success = true
            @messages = []

            started_at = Time.zone.now

            # ここでJob本体の処理が実行されます
            yield

            ended_at = Time.zone.now

            elapsed_time = (ended_at - started_at) * 1000
          rescue => e
            @success = false
            @messages << e.to_s
            Bugsnag.auto_notify(e)
          ensure
            body = {
              timestamp: Time.zone.now.to_i,
              started_at: started_at,
              ended_at: ended_at,
              elapsed_time: elapsed_time,
              success: @success,
              messages: @messages,
              worker: worker.class.to_s,
            }
            @logger.info(body)
          end
        end
      end
    end
  end
end

このMiddlewareをShoryukenに積むにはconfig/initializes配下に適当なファイルを置いて以下のように追記します。

Shoryuken.configure_server do |config|
  config.server_middleware do |chain|
    chain.add Shoryuken::Middleware::CustomMiddleware::Server::ProcessingTimeMeasure
  end
end

まとめ

今のところ安定して稼働していますが、基盤としてはまだ汎用的なつくりにはなっていないので、汎用基盤として稼働させていくためには以下のような機能が必要になりそうだと考えています。

• 処理時間に制限があるJobの時間が経過した場合に通知する(Shoryuken workerの数を増やすタイミングを見極めるための何か）
• Job管理(workflow系ツールの導入など？）
• Shoryukenのプロセス監視と自動復旧

今後も開発を続けながら、何かシェアできる知見が得られたらまた開発者ブログに書きたいと思います。

お約束

トレタはエンジニアを募集しています。iPadアプリやAPIの開発以外に、こういった基盤開発にも興味があるエンジニアはぜひご応募ください。

www.wantedly.com

www.wantedly.com