Kuroko2の近況

技術部開発基盤グループの大石です。

先日、弊社主催のイベント CookpadTechKitchen#8 〜舞台裏を支える黒衣たち〜 にて、「Kuroko2の近況とクックパッドのバッチ周りの概況」というテーマで発表させて頂きました。今回はこの発表内容の中でも Kuroko2 についてピックアップして紹介したいと思います (今回の記事ではクックパッドのバッチの概況については特に触れませんが下記資料を参照ください)。

Kuroko2 とは

Kuroko2とは、Ruby製のWebベースのジョブスケジューラーです。2014年にクックパッド社内で開発され、2016年の秋にオープンソースとして公開しました

詳細については、当ブログの クックパッドのジョブ管理システム Kuroko2 の紹介Kuroko2 リポジトリのドキュメント をご覧ください。

また、Kuroko2 のオリジナル作者である弊社高井の社内用のLT資料 The Design Philosophy of Kuroko2 が公開されており、kuroko1 の事例を元に Kuroko2 が採用しているアーキテクチャの背景を知ることができます。 Kuroko2 の内部についても説明されているため、Kuroko2 へコントリビュートする際にとても参考になる良い資料だと思います。

今回はこれらの資料にある背景に加えて Kuroko2 をOSS化するにあたって意識していた Kuroko2 の方針、そして実際に Kuroko2 をカスタマイズする方法を紹介したいと思います。

Kuroko2の方針

ジョブ管理、ワークフロー管理への要求はトレンドや新たな技術の登場によって細かな要求が今後も変わってくることが予想されます。 そのため、Kuroko2 はメンテナンスや拡張が行いやすいシンプルな設計を保つこと、様々な現場にあわせた拡張性を担保するために本体はシンプルに保っていくべきだと考えています。

そのために以下を方針として意識しました。

1. 現実的な運用を見据えた安定した設計を保つ

The Design Philosophy of Kuroko2 p.19 にある通り、Kuroko2 は実際にクックパッドのバッチ運用を通して現実的な現場を意識して作られたものです。 闇雲に最先端の技術を採用するのではなく、あえて管理のしやすさを優先して枯れたアーキテクチャを採用し、安定した運用ができるような設計を保っていくべきだと考えています。

2. 煩雑になりがちなバッチジョブ管理の問題をUIで解決する

Kuroko2 の特徴として、煩雑になりがちなバッチ管理の方法をUIがフレームワーク的にアシストしていることが挙げられます。 具体的には、ジョブ定義の際にジョブの説明を書くためのテンプレートが用意されていたり、ジョブのお気に入り機能、自分の管理するジョブが一覧で見れるダッシュボードなどクックパッドでの運用を通して必要とされたものが実装されています。

この点は Kuroko2 の良い点であり今後も重点的に改善を進めていくべき点だと思っています。ただし、当初よりフロントエンドのアーキテクチャが古くなっており、その改良は課題であると思っています。

3. スケジューラーと汎用性の高いワークフロー管理に徹する

Kuroko2 のコアになる役割は、スケジューラーとワークフロー管理に限定し、新しい役割を定義はしないようにします。 また本体にあるタスク(docs/task.md) は汎用性の高いものだけを定義し、Kuroko2 が利用されているドメインに特化したものはカスタムタスクを利用することで柔軟性を確保するようにします。

4. うまく外の機構と連携する

ワーカーが実行する処理については、現在 command-executor からシェル経由でコマンドが実行されるのみです。この部分についても特定の機構に依存するものを本体にいれるべきではなく、うまく外の機構と連携できるように目指すべきだと考えています。 弊社が採用している例として、DWHに関連する処理についてはSQLバッチフレームワークである Bricolage を利用し、AWS ECS タスクの実行は Hako を利用することでそれぞれのドメインに合わせた連携を行っています。

ただしこの点において、シェル経由は起動コストが高いという問題があり、高頻度のジョブなどで問題が出ているため command-executor と kuroko2 console との間の連携の抽象化をしてもう少し効率的な連携が行えるような改善の必要性があると認識しています。

5. 必要な部分だけに開かれた拡張性

Kuroko2 は Rails の Mountable Engine になっており、それを gem として配布しています。 この方法を採用した理由は、Kuroko2本体の機能は常にアップデート可能なように管理できて、かつ必要に応じてカスタマイズしたかったためです。 具体的には、先述したカスタムタスクの定義や、後述する Kuroko2::ApplicationController を拡張という機能を想定しています。

Kuroko2 はバッチを管理する上で生じるドメインに特化した細かなカスタマイズを行えるようにして、様々な現場に合わせるための拡張性を適切に提供できるようにしたいと考えています。

Kuroko2 を拡張してみる

それでは、先述したカスタムタスクと Kuroko2::ApplicationController への拡張の具体的な方法のサンプルを紹介したいと思います。

カスタムタスク

まず kuroko2 gem をマウントしているRailsアプリケーション内にカスタムタスクを置く場所を作ります (後述する kuroko2.yml の設定でnamespaceは任意に分けることはできますが、今回は簡単のため Kuroko2::Workflow::Task 以下にしています)。

$ cd your_kurko2_rails_apps/
$ mkdir -p lib/kuroko2/workflow/task/

次にカスタムタスク本体のコードを上記のディレクトリ以下に置きます。

module Kuroko2
  module Workflow
    module Task
      class MyProjectRunner < Execute
        def chdir
          '/home/alice/my_project'
        end

        def shell
          "./bin/rails runner -e production #{Shellwords.escape(option)}"
        end
      end
    end
  end
end

この例では、ワーカーに設置された任意のRailsアプリケーションの中で option で渡された任意のコードを実行できます。

このカスタムタスクを kuroko2.yml で設定して、利用可能な状態にします。

....
  custom_tasks:
    my_project_runner: MyProjectRunner
....

以上の設定で、kuroko2 script 内で

 env: VAL1=A
 env: VAL2=B
 my_project_runner: MyProject::Batch.run

のようにKuroko2とは別のRailsアプリケーション内のバッチを実行するための専用のカスタムタスクを設定することができます。

クックパッドでもこのようなアプリケーション毎に設定などをまとめた専用のカスタムタスクを定義していたり、Hako を利用した Docker アプリケーションへのオプション定義のショートカットとして利用しています。 また、実験的なタスクを試したりすることもできるので、Kuroko2 本体にコントリビュートする際にも事前に検証などが行なえます。

Kuroko2::ApplicationController の拡張

次に Kuroko2::ApplicationController を拡張する方法を紹介します。

ここでなぜこのような拡張が必要なのかという理由を先に述べておきます。 クックパッドではアプリケーションのエラートラッキングに Sentry を採用しており、kuroko2 gem をマウントしたアプリケーションも他のアプリケーションと同様にエラーが発生した場合に Sentry で管理したいということがあったためです。

それでは、実際に拡張する例を書いてみます。

カスタムタスクと同様に以下の拡張コードを your_kurko2_rails_apps/lib 以下に置きます。(アプリケーションがロードできる場所であればどこでもよいです)

module ControllerExtention
  extend ActiveSupport::Concern
  included do
    before_action :additional_before_action
  end

  private

  def additional_before_action
    if signed_in?
      # do something
    end
  end
end

次に、こちらもカスタムタスクと同様に kuroko2.yml に設定を行います。

...
extentions:
  controller:
    - ControllerExtention
...

今回の例はユーザーがログインしている場合になにかを行うような例にしました。 先述したクックパッドで行っている Sentry を用いたエラートラッキングでは、before_action でログインユーザーやエラーが発生したときに必要なコンテキストを設定するようなことを行っています。

Mountable Engine を採用した利点として、 kuroko2 gem がマウントされたRailsアプリケーションからある程度のカスタマイズが可能になる点です。 いまは ApplicationController だけですが、必要があればこのような拡張性はある程度確保したいと考えています。

Kuroko2 のこれから

方針の中でもすこし触れましたが、具体的には、

  • UIをモダンに改善する
  • command-executor と kuroko2 console 間の連携の抽象化
  • command-executor 自体を Rails に依存しないようにして、軽量化する
  • ドキュメントの充実

など、Kuroko2 の方針に追いつけていない部分がまだまだあると認識しています。 ひとまずはこれらの課題に対して取り組んでいく必要があると考えています。

イベントで出た一部の質問とその回答

権限管理は実装しないのか

実装する予定はいまのところありません。

ジョブの実行前は確認のモーダルウィンドウが出るので誤って実行されにくいUIをしています。 さらにクックパッドではジョブを管理しているチーム以外にもたとえば障害が起きたときなど SRE や開発基盤がジョブの description をみて適宜リトライを行うようなオペレーションを行っています。DWHの領域では部署をまたがったジョブの連携が行われておりお互いにアクセスできる必要があります。またジョブに対する操作が行われた場合、いつ誰が実行・リトライしたかをログとして記録しています。 このため厳しく権限管理をするよりも性善説にたって誰でもアクセスできるようにしておいたほうがメリットが大きいと考えています。

Kuroko2::ApplicationController の拡張を使ってカスタマイズという形で実装することは可能だと思うので、必要があればこちらの方法をおすすめします。

補足: 現在認証については Google の G Suite のみがサポートされていますが、この点については将来的に他の認証方法などの対応は必要になってくるのかなとは感じています。

command-executor がメモリを食う

Railsに依存しすぎている部分がたしかにあるので対応したいです。 必要以上にRailsに依存しないようにすることと、方針の中で触れた command-executor の抽象化も含めて今後の課題だと認識しています。

最後に

Kuroko2 の設計方針とこれからの課題、拡張方法について紹介しました。 この記事で興味を持たれたり、導入してみたいという方は是非 Kuroko2 までコントリビュートお待ちしています。 また、実際に導入したなどの事例やフィードバックなどもご連絡頂けると幸いです。

f:id:eisuke-oishi:20170614172135p:plain

Android アプリのリソース定義ポリシーを整備した話

技術部モバイル基盤グループの児山(@nein37)です。 モバイル基盤グループではモバイルアプリの開発だけでなく、開発環境の整備や開発効率の向上も重要な目的の一つとしています。

昨年、開発効率向上の一環として行っているアプリのリソース整理の取り組みについてAndroidアプリのリソースを整理して開発効率を改善した話という記事で紹介させて頂きました。 今回はそれから1年が経過してリソース整理の状況がどのように変わったか説明していきたいと思います。

前回のあらすじ

詳細は前回の記事に書いてありますが、大体以下のような取り組みを行いました。

  • 未使用リソースの削除
  • Theme の定義
  • Style の整理
  • TextAppearance の定義

これらの作業により、無法地帯だったクックパッドアプリのリソースを整理し、開発効率を大幅に改善することができました。 (と、その当時は思っていました…)

その後発生した様々な問題

トップ画面の大規模変更

去年の9月ごろ行った更新により、アプリのトップ画面の構成が大きく変化しました。

変更前 変更後
f:id:nein37:20170601193414p:plain f:id:nein37:20170601193420p:plain

この変更にあわせて、以下のようなリソース修正が行われました。

  • 新しいトップ画面にあわせて Style や TextAppearance を追加した
  • 新しいトップ画面に関する大量の Dimen 定義が追加された
  • 元々の定義の一部が他の画面から利用されていたため消さずに残した

画面ごとの Style の乱立

アプリ全体で利用できる汎用的な Style や TextAppearance に関しては前回の作業で定義済みだったのですが、実際にアプリの更新をしていく上で汎用的なリソースでは表現できない様々なデザイン上の例外が追加されていきました。

  • この画面のこの場所は目立たせたいので 16sp にしたい
  • この場所は普通のグレーじゃなくて暖かみのあるグレーにしたい… などなど

この当時の命名規則が細かく定まっていなかったため、ある Style がどの画面用のものなのかわからなくなってしまうという問題も発生しました。 Style のスコープがわからないため元々ある Style を再利用しても良いのかどうか判断できず、似たような Style 定義がどんどん追加されていくだけの状態になっていました。

Style 定義の度に質問が飛んでくる

すでに説明してきたとおり、 Style を新規追加するときの命名規則が緩く、定義を追加するかどうか判断するためのフローもなかったため、以下のような質問が押し寄せてくることになりました。

  • この定義を追加したいんですが良いですか?
  • この Style のはこの名前で良いですか?
  • 継承元これで良いですか?

などなど。 それぞれ考えるとちゃんと答えは出るものの、毎回エンジニアもデザイナーも悩ませてしまい、単純な Style の追加作業に関して手間取らせてしまっていました。

改善に向けて

上記のように本当にいろいろな問題が出てきましたが、これまでのポリシーでも追加するときは既存の定義を真似して追加されていくので一定の秩序はありました。 すくなくとも、去年までの無法地帯よりははるかにマシです。

そこで、これまでのポリシーをベースにしながら今回出てきた問題を踏まえてこれまでの運用で問題が出たところを見直し、新しいポリシーを整備することにしました。 ここまでで出てきた反省点を改めてまとめると以下のようなものです。

  • 汎用リソースだけではカバーできない部分が多い
    • 例外の存在を前提にする必要があった
  • 例外的なリソースを定義する方法が未定
    • リソースの定義方法(命名規則、定義場所)を決める必要があった
    • Style(TextAppearance) 以外のリソースでも決めておいたほうが良かった
  • あたらしくリソース定義をした場合、どれが汎用リソースでどれが例外リソースなのかわからない
    • 命名規則や記述ファイルで区別可能にしておく必要があった

これらの反省点を踏まえ、以下のような方針でリソースの定義ポリシーを整えることにしました。

  • 本当に汎用的に使える部分のみ汎用リソースとして定義する
    • 汎用リソースは記述ファイル名、命名規則などで容易に判別可能にする
    • 将来的に汎用にできるかも…などの曖昧な根拠で汎用リソースにしない
  • 汎用リソースで表現できないものに関しては「画面ごとのリソース」として定義する
    • 画面ごとのリソースは記述ファイル名、命名規則などで適用範囲を判別可能にする
    • 他の「画面ごとのリソース」と同じ定義をしようとしている場合、そのリソースの汎用リソース化を検討する

いままでのポリシーとの違いは主に「アプリ全体で利用するリソースとある画面のみで利用するリソースを明確に区別できるようにする」「あるリソースを汎用リソースにするかどうかを決めるタイミングを明確化する」という2点です。

次項ではリソースの種類ごとに実際の命名規則について説明していきます。

実際の定義ポリシー

Color

Color リソースはその名前の通り色の定義を行うものです。 前項と若干矛盾しますが、 Color リソースに関しては定義数が多くなく今後も一括管理可能な範囲に収まるという認識で画面ごとのスコープは設けていません。

クックパッドアプリでは Color リソースの定義に以下のような制約を持たせています。

  1. 実装上の制限がない限り、色の指定は Color リソースを参照させる
  2. アプリ内で多用される基本的な色には orange 、 green などの汎用的な名前をつける
  3. 各色については用途別に名前をつける(2.で定義した色を参照しても良い)
  4. ColorStateList 、gradient 用の色は名前を揃える(2.で定義した色を参照しても良い)

実際の定義は以下のようになります。

<!-- 2. で言及している基本的な色群 -->
<color name="green">#8bad00</color>
<color name="orange">#ff7f00</color>
<color name="red">#ef6074</color>

<!-- 3. で言及している用途別の色群 -->
<color name="recipe">@color/green</color>
<color name="ranking_arrow_up">@color/orange</color>
<color name="ranking_arrow_stay">#b8af93</color>
<color name="ranking_arrow_down">#32a9c0</color>

<!-- 4. で言及している用途別の色群 -->
<color name="button_background_primary">@color/orange</color>
<color name="button_background_primary_pressed">#da6e00</color>
<color name="button_background_primary_disabled">#ffc17d</color>
<color name="button_text_primary">@color/white</color>
<color name="button_text_primary_pressed">#d9d9d9</color>
<color name="button_text_primary_disabled">#ffe5c9</color>

Dimen

Dimen リソースはViewのサイズや文字サイズ、マージンなどを定義するためのものです。

こちらは画面ごとの定義が非常に多いため、画面ごとのスコープを導入し、以下のような制約を持たせています

  1. 実装上の制限がない限りサイズ指定は Dimen リソースを参照させる
  2. アプリ全体で利用する Dimen の基本単位は dimens_base.xml に記述する
    • このとき定義するリソース名は dimen_xxdp とする
  3. アプリ全体で利用する汎用的な定義は dimens_base.xml に記述する
    • このとき定義するリソース名は general_用途名 とする
    • 値の定義は可能な限り dimen_xxdp を参照する
  4. 画面ごとの定義は dimens.xml に記述する
    • このとき定義するリソース名は 画面名_用途名 とする
    • 値の定義は可能な限り dimen_xxdp を参照する

dimens_base.xml の定義は以下のようになります。

<!-- 2. で言及している Dimen の基本単位群 -->
<dimen name="dimen_2dp">2dp</dimen>
<dimen name="dimen_4dp">4dp</dimen>
<dimen name="dimen_8dp">8dp</dimen>
<dimen name="dimen_12dp">12dp</dimen>
<dimen name="dimen_16dp">16dp</dimen>
<dimen name="dimen_20dp">20dp</dimen>
<dimen name="dimen_24dp">24dp</dimen>
<dimen name="dimen_32dp">32dp</dimen>
<dimen name="dimen_48dp">48dp</dimen>
<dimen name="dimen_56dp">56dp</dimen>
<dimen name="dimen_64dp">64dp</dimen>

<!-- 3. で言及している汎用的な定義 -->
<dimen name="general_padding">@dimen/dimen_12dp</dimen>
<dimen name="general_text_padding">@dimen/dimen_12dp</dimen>
<dimen name="general_card_padding">@dimen/dimen_12dp</dimen>
<dimen name="general_text_drawable_padding">@dimen/dimen_8dp</dimen>
<dimen name="general_dialog_padding">@dimen/dimen_8dp</dimen>

dimens.xml の定義は以下のようになります。

<!-- 4. で言及している画面ごとの定義 -->
<dimen name="user_registration_activity_top_margin">@dimen/dimen_24dp</dimen>
<dimen name="user_registration_activity_bottom_margin">@dimen/dimen_24dp</dimen>
<dimen name="user_registration_contents_margin_top">@dimen/dimen_12dp</dimen>
<dimen name="user_registration_paragraph_margin_top">@dimen/dimen_32dp</dimen>
<dimen name="user_registration_paragraph_margin_top_small">@dimen/dimen_24dp</dimen>

わざわざ dimen_xxdp という Dimen リソースを定義しているのが不思議に思えるかもしれませんが、これはデザイナーが画面設計をする際に値をなるべく選択肢の中から選ぶようにすることで統一感を出しやすくするための仕組みです。 また、dimen_xxdp を参照していないリソースを「設定値からみても明らかに例外として定義されているもの」として判別することができるようになり、後のリソース整理でも役立てることができ(る予定になってい)ます。

Style

Styleリソースはある種類の View の属性をまとめて定義するためのものです。 詳しい定義ポリシーに入る前に、 Style 特有の注意点についていくつか説明していこうと思います。

再利用性を高めるために

アプリデザインの統一感を保つ上で、 Style は非常に重要です。 複数の画面で同一の Style を使いまわすことで View の見た目を揃えることができるため、 Style 定義においては定義内容の再利用性を高めることが重要になります。 個人的に再利用性を高めるためになるべく Style に定義しないほうが良いと考えている属性は以下のようなものです。

  • layout_gravity
  • layout_weight
  • layout_above
  • layout_below(など、配置に関するもの全般)

これらの layout_* という属性は View ではなく LayoutParams の属性で、親Viewの種類や属性によっては機能しなかったり意図しない動作になったりします。 layout_width, layout_height, layout_margin あたりは大抵の ViewGroup で動作しますが、上に挙げたような属性は特定の ViewGroup でしか動作しません。 (このあたりは 各 LayoutParams の継承を見るとわかりやすいです) Android ではレイアウトファイルの include による再利用もできるようになっているので、特定のView階層構造に依存している場合はincludeを活用するなど再利用性を高める工夫をしていくと良いと思います。

継承の仕組み

Style リソースは「 parent 指定による継承」と「名前による継承」の2つの仕組みを持っています。 この2つを組み合わせることで様々な Style 定義を効率的に行うことができます。

parent 指定による継承

parent 指定による継承では親 Style を直接継承して派生 Style を作ることができます。 これは主に Android やサポートライブラリの Style を継承する場合に利用します。

<!-- AppCompatのボタンStyle定義を継承してクックパッドのボタンStyle定義を行う例 -->
<style name="CookpadStyle.General.Button" parent="Widget.AppCompat.Button">
    <item name="android:background">@drawable/button_background_default</item>
    <item name="android:textAppearance">@style/CookpadFont.General.Button.Text</item>
    <item name="android:paddingTop">@dimen/button_padding_vertical</item>
    <item name="android:paddingBottom">@dimen/button_padding_vertical</item>
    <item name="android:paddingLeft">@dimen/button_padding_horizontal</item>
    <item name="android:paddingRight">@dimen/button_padding_horizontal</item>
    <item name="android:drawablePadding">@dimen/button_drawable_padding</item>
    <item name="android:minWidth">@dimen/button_min_width</item>
    <item name="android:minHeight">@dimen/button_min_height</item>
    <item name="android:textColor">@color/button_text_state</item>
</style>

名前による継承

すでに存在する Style 名に .(ドット) で続けて別の名前を与えることでその Style を継承することができます。 これは主に定義済みの Style のバリエーションを増やすために利用します。

<!-- CookpadStyle.General.Button を継承して Primaryボタン用のstyle定義を行う例 -->
<style name="CookpadStyle.General.Button.Primary">
    <item name="android:background">@drawable/button_background_primary</item>
    <item name="android:textColor">@color/button_text_primary_state</item>
</style>

クックパッドにおける Style 定義のポリシー

以上の注意点を踏まえたクックパッドの Style 定義は以下のようになります。

  1. 汎用的な Style 定義は styles_widget.xml に記述し、以下の要素をドットで繋いだリソース名とする
    • CookpadStyle(prefix)
    • General(汎用Style定義)
    • View(対象Viewの種類)
    • Variation(バリエーション、必須ではなく複数でも可)
  2. 汎用 Style 定義のうち、バリエーションが特に多いものに関しては View 種類ごとにファイルを切り出す
    • styles_button.xml など
  3. それ以外の Style 定義については styles.xml に記述し、以下の要素をドットで繋いだリソース名とする
    • CookpadStyle(prefix)
    • Screen(画面)
    • View(対象Viewの種類)
    • Variation(バリエーション、必須ではなく複数でも可)

汎用 Style 定義の例

<!-- 汎用のボタンStyleのうち、最も基本的なもの -->
<style name="CookpadStyle.General.Button" parent="Widget.AppCompat.Button">
    <item name="android:background">@drawable/button_background_default</item>
    <item name="android:textAppearance">@style/CookpadFont.General.Button.Text</item>
    <item name="android:paddingTop">@dimen/button_padding_vertical</item>
    <item name="android:paddingBottom">@dimen/button_padding_vertical</item>
    <item name="android:paddingLeft">@dimen/button_padding_horizontal</item>
    <item name="android:paddingRight">@dimen/button_padding_horizontal</item>
    <item name="android:drawablePadding">@dimen/button_drawable_padding</item>
    <item name="android:minWidth">@dimen/button_min_width</item>
    <item name="android:minHeight">@dimen/button_min_height</item>
    <item name="android:textColor">@color/button_text_state</item>
</style>

<!-- 汎用のレシピボタンStyle -->
<style name="CookpadStyle.General.Button.Recipe">
    <item name="android:background">@drawable/button_background_recipe</item>
    <item name="android:textColor">@color/button_text_recipe_state</item>
</style>

<!-- 汎用のレシピボタンStyleにマージンを付与したもの -->
<style name="CookpadStyle.General.Button.Recipe.WithMargin">
    <item name="android:layout_marginTop">@dimen/button_margin_vertical</item>
    <item name="android:layout_marginBottom">@dimen/button_margin_vertical</item>
    <item name="android:layout_marginRight">@dimen/button_margin_horizontal</item>
    <item name="android:layout_marginLeft">@dimen/button_margin_horizontal</item>
</style>

画面ごとの Style 定義の例

<!-- ユーザー登録画面用のEditText Style -->
<style name="CookpadStyle.UserRegistration.EditText">
    <item name="colorControlActivated">@color/orange</item>
    <item name="android:textCursorDrawable">@drawable/edit_text_cursor_orange</item>
    <item name="android:background">?android:attr/editTextBackground</item>
    <item name="android:textColorHint">@color/extra_light_gray</item>
</style>

汎用 Style 定義と画面ごとの Style 定義を比べてみると、まず第2句が General かどうかで汎用 Style かどうか判別可能になっていることがわかると思います。 General であればアプリ全体に適用可能な汎用 Style 、そうでなければ画面ごとのスコープをもった Style です。 また、第4句以降が存在している場合、元々存在する Style のバリエーションであることもわかり、 Style 名から定義内容を追う上で役立ちます。

TextAppearance

TextAppearance は文字表示に関する属性だけをまとめた Style のサブセットです。 継承などの仕組みは Style に準じていますが、クックパッドアプリではStyleとの大きな違いとして Base TextAppearance という概念が導入されているので先にそちらを説明します。

Base TextAppearance の定義

前回のリソース整理記事でもちらっと触れていますが、クックパッドアプリでは基本的な文字サイズ・文字色・文字スタイルの組み合わせを Base TextAppearance として定義しています。 これは dimen_xxdp 同様、デザイナーの新しい TextAppearance に制約を課すために使われています。

  1. Base TextAppearance は text_appearance_base.xml に記述し、以下の要素をドットで繋いだリソース名とする
    • CookpadFont.Base(prefix)
    • 文字サイズ(5種類:ExtraLarge/Large/Default/Small/ExtraSmall)
    • 文字色(7種類:未指定(Black)/Gray/LightGray/Green/Orange/Red/White)
    • 文字スタイル(2種類:未指定(標準)/Bold)
  2. 上記の定義について、すべての組み合わせを定義する
  3. Base TextAppearance は これを継承した TextAppearance を定義する以外の目的で利用しない
    • レイアウトファイル内などで直接参照しないこと

Base TextAppearance の定義例

<style name="CookpadFont.Base.ExtraLarge">
    <item name="android:textColor">@color/black</item>
    <item name="android:textSize">@dimen/extraLargeTextSize</item>
</style>

...

<style name="CookpadFont.Base.ExtraLarge.Gray">
    <item name="android:textColor">@color/gray</item>
</style>

...

<style name="CookpadFont.Base.ExtraLarge.Gray.Bold">
    <item name="android:textStyle">bold</item>
</style>

という感じで名前による継承を使いつつ70種類を網羅しています。

TextAppearance の定義

  1. TextAppearance は text_appearance.xml に記述する
  2. 汎用的なTextAppearance 定義は以下の要素をドットで繋いだリソース名とする
    • CookpadFont(prefix)
    • General(汎用)
    • Purpose(目的)
    • Style(書体:Emphasis/Main/Sub/Weaken)
  3. それ以外の TextAppearance 定義は以下の要素をドットで繋いだリソース名とする
    • CookpadFont(prefix)
    • Screen(画面)
    • Purpose(目的)
    • Style(書体:Emphasis/Main/Sub/Weaken)

Purpose(目的) はその TextAppearance を何の表示のために定義するかを書くところで、例えば「RecipeTitle」や「UserName」といったものが入ります。 Style(書体)はその TextAppearance が同一のスコープ、目的の中でどういう位置づけにあるかを示しています。 このStyle(書体)の概念は Base TextAppearance の文字サイズや太字などとは無関係に定義されるもので、「このスコープ、目的に関してはこの組み合わせが Main 」「この組み合わせが Sub 」という定義をデザイナーが相談しながら決定しています。

TextAppearance の定義例

<!-- 汎用のレシピタイトル -->
<style name="CookpadFont.General.RecipeTitle.Main" parent="CookpadFont.Base.Large.Green.Bold" />

<!-- 汎用のレシピタイトル(小) -->
<style name="CookpadFont.General.RecipeTitle.Sub" parent="CookpadFont.Base.Default.Green.Bold" />

<!-- 汎用のレシピタイトル(強調) -->
<style name="CookpadFont.General.RecipeTitle.Emphasis" parent="CookpadFont.Base.ExtraLarge.Green.Bold" />

<!-- レシピ一覧画面におけるレシピタイトル -->
<style name="CookpadFont.RecipeList.RecipeTitle.Main" parent="CookpadFont.Base.Small.Green.Bold" />

Styleと同様に、第2句の内容を見ることでその TextAppearance が汎用定義なのか画面ごとの定義なのかを知ることができるようになりました。 TextAppearance はすべての定義が Base TextAppearance を parent によって継承するため名前による継承が行われないので少しシンプルですね。

まとめ

これまで説明してきたようなリソースの定義ポリシーを策定したことで、各リソースのスコープや意味合いについて格段に管理がしやすくなりました。 アプリの改修によってリソース自体が増殖していくという問題は引き続き発生しますが、画面スコープなどの導入によって今後無秩序な状態に陥ることはなくなったと思います。 こういった Style や TextAppearance のルールづくりは非常に地味で面倒な作業ですが、長期的にはエンジニア・デザイナー双方の作業を効率化することができます。 今回定義ポリシーを策定するにあたってはデザイナーとつきっきりで「どういう場合に例外リソースの定義が必要か」「例外はどういったスコープで捉えれば良いか」というような事について話しながら進めました。 特に dimen_xxdp による制約や TextAppearance の文字サイズの定義と連動しない4段階の Style(書式) といった概念はデザイナーの提案から生まれたものです。 こういった細かい部分にまでデザイナーの思想を反映していくことでエンジニア・デザイナーの意思疎通が少しでも簡単になればと思っています。

時系列データベースに関する基礎知識と時系列データの符号化方式について

こんにちは。インフラストラクチャー部 SRE グループの吉川 ( @rrreeeyyy ) です。今期オススメのアニメはツインエンジェル BREAK です。

普段の業務並びに趣味の一環として、サーバのモニタリング環境の調査や改善に取り組んでいます。 そこで本稿では、モニタリングのコンポーネントの一つとして外すことが出来ない、時系列データベースの基礎知識に関して紹介します。

そもそも時系列データ・時系列データベースとは?

時系列データというのは、特定の時間ごとに何らかの値を取得した際の、取得した一連の値を指します。 例えば、以下のようなフォーマットをしたデータなどは時系列データにあたるでしょう。

timestamp1,key,value1
timestamp2,key,value2
timestamp3,key,value3
:

時系列データベースとは、上記のような時系列データの保存・処理に特化したデータベースです。 Web インフラストラクチャーの文脈では、サーバのメトリクス等が時系列データにあたります。

Web サービスの文脈では、Web サーバの増加や複雑化により、高い解像度の様々なメトリクスを長期間保持したいという要望や、 サーバのメトリクスをより統計的に解析し、アラーティングの精度を向上させたいという要望などがあり、 様々な会社や組織で独自の時系列データベースが開発されているという事情があります。

数年前の時系列データベース

最近の時系列データベースの話をする前に、数年前の時系列データベース界隈の状況を少しだけ振り返ってみます。 数年前に主流であった時系列データベースとして、RRDtoolGraphite などがあります。

これらの時系列データベースはシンプルであるため、時系列データベースの基本的な機能を知るには有用です。しかし、様々な問題点があるのも事実です。

RRDTool では、時系列データの作成・更新・グラフの作成をする際にコマンドラインでオプションを複数指定する必要があります。 グラフの作成で使えるコマンドラインオプションは、柔軟である一方で、SQL などの標準化された書式などではなく、一部の習熟したエンジニアのみが扱える状況でした。 また、時系列データの内部的な扱いに関しても、符号化や分散などのスケーラビリティを考慮されたものではなく、大量のデータを蓄積にするにつれて、 更新や、複雑な解析をした場合に掛かる時間が線形的に増えていき、要求を満たせないという問題点がありました。

Graphite に関しては、現在でも非常に安定して動いており、様々な会社で採用されている優れた時系列データベースと言えそうです。 スケーラビリティに関しても、Graphite に関する様々なツールが OSS で開発されていたり、様々な分散構成の資料がカンファレンスなどで公開されています。 データの更新方法に関しても、HTTP API を用意しており、Graphite 形式と互換の HTTP API で書き込むことが出来る時系列データベースが新たに開発されている程度には普及しています。 一方で、時系列データを保存する構造に関しては非常に単純であるために、時系列データにタグを付けて管理・解析することや、 数秒単位でデータを書き込み続けた場合に、高性能なストレージを複数用意する必要があるなどの、いくつかの課題が未だに残っているような状態です。

その他にも、検索エンジンや RDBMS 等を時系列データベースとして利用するケースも増えてきています。 これらは、非常に安定したストレージエンジンとしての実績や、標準化された SQL などを統計手法として扱うことが出来るという特色があります。 その一方で、時系列データ専用に作られたものではないため、時系列データの解像度を上げ、数秒程度の間隔で同じデータを書き込み続けた場合、ストレージ容量の肥大化が発生したり、 頻繁に解析を行うためには、メモリを多く確保する必要がある等の問題点があることがあります。

上記のような都合から、更に時系列データの取り扱いや、時系列データの統計的解析のみに更に特化したデータベースを開発するという流れが発生してきていました。

最近の時系列データベース

最近出てきた時系列データベースとして、InfluxDB や、Gorilla(Beringei) などがあります。 これらを含め、最近の時系列データベースでは共通して、時系列データの符号化方式や、メモリもしくはストレージの使用法などのアーキテクチャに工夫がなされており、 ストレージ容量の節約や、解析時に使用するメモリ量の削減などの効果を上げることに成功しています。 また、ほとんどの時系列データベースにおいて、SQL 等をベースにしたデータ解析の方法が用意されているという特色もあります。

double-delta-encoding や XOR encoding と呼ばれるような、時系列データ内の差分を利用した符号化方法は、最近の多くの時系列データベースで使用されています。 詳細は、Facebook の作っている時系列データベースである Gorilla の論文にありますが、簡単に説明します。

double-delta-encoding (timestamp)

double-delta-encoding は、時系列データのタイムスタンプが等間隔に配置される事に着目し、タイムスタンプ値の符号化を行う方法です。 具体的には、次のように計算された値を使用して、タイムスタンプ値として実際に格納する値を決定します。 ここで、t_n は n 番目の時系列データのタイムスタンプ値とします。

f:id:rrreeeyyy:20170525225447p:plain

書き込む値は、上記で計算した D の値によって決まります。具体的には次のようなルールになります。

  • D の値が 0 の場合、0 をそのまま書き込むため、単一ビットのみの容量で済みます。
  • D の値が [-63, 64] の区間内にあった場合、10 の後に D (7bits) の値を格納します。
  • D の値が [-255, 256] の区間内にあった場合、110 の後に D (9bits) の値を格納します。
  • D の値が [-2047, 2048] の区間内にあった場合、1110 の後に D (12bits) の値を格納します。
  • 上記のルール以外の場合、1111 の後に 32bits を使用して D の値を全て格納します。

このルールだけだと分かりづらいので、具体的な例で見ていきましょう。次のような時系列データのブロックを仮定します。 このブロックが作られた時間を、先頭に値無しのタイムスタンプとして表現しています。

1343232000
1343232062,value1
1343232122,value2
1343232182,value3

delta 並びに delta-of-delta を計算してみます。

1343232000        #=> block header
1343232062,value1 #=> delta: 62
1343232122,value2 #=> delta: 60, delta-of-delta: -2
1343232182,value3 #=> delta: 60, delta-of-delta: 0

先頭のタイムスタンプは、時系列データのブロックヘッダとして格納します (64bits)。

value1 のタイムスタンプは、まだ差分の差分を計算することが出来ません。 Gorilla では、時系列データのブロックを 4 時間 (16,384 秒) ごとに作成する事を仮定しているため、 最大限遅れたとしてもブロックヘッダのタイムスタンプと value1 のタイムスタンプの差分は、16383 (14bits) で収まります。 そのため、ブロックヘッダの次の値としては 14bits を利用して、62 (00000000111110) を書き込みます。

その先からは、先ほど説明したルールに基づいて値を書き込んでいきます。 value2 の delta-of-delta は -2 であるため、10 を書き込んだ後に 7bits を使用して -2 (1111110) を書き込みます。

value3 の delta-of-delta は 0 であるため、そのまま 0 を書き込みます。

これで 4 つ分のタイムスタンプの表現を書き込むことが出来ました。 ブロックヘッダから順に数えていくと、64bits, 14bits, 9bits, 1bit となり、 合計 88bits で 4 つ分のタイムスタンプを表現することに成功しています。

仮に、4 つ分のタイムスタンプを全て符号化無しで書き込んだ場合は、64 * 4 = 256bits を使用することになるため、 大きく符号化することに成功していると言えそうです。

また、この符号化方法は、時系列データが規則正しく並んでいれば並んでいるほど符号化効率が良くなる事が重要になっています。

XOR encoding

先ほどはタイムスタンプの符号化について確認しました。 タイムスタンプの場合と同じく、サーバのメトリクスやセンサデータについても、 多くの場合で、異常がない限り似た値を推移する可能性が高い、という性質があります。

次のような double 型の値を持つ時系列データを書き込む事を考えます。

timestamp1,12.0
timestamp2,24.0

近い値で推移する double 値を効率よく書き込むため、まず 2 値の XOR を取る戦略を取ります。 これは、近い値の XOR を取った場合、浮動小数点の符号部と、指数部並びに仮数部の上位ビットは 0 になりやすい、という特性があるためです。

例として、いくつかの近い 2 値の XOR を取った値を列挙していきます。

12.0 ^ 24.0 #=> 0000000000010000000000000000000000000000000000000000000000000000
24.0 ^ 15.0 #=> 0000000000010110000000000000000000000000000000000000000000000000
15.0 ^ 12.0 #=> 0000000000000110000000000000000000000000000000000000000000000000

この時、12.0 ^ 24.0 では先頭の 11 個の 0 並びに 1 の後に続く全ての 0 が符号化出来そうだと考えられます。 この時の有意なビット (meaningful bits) は 1 のみであると考えられます。

24.0 ^ 15.0 でも、先頭の 11 個の 0 並びに、1011 の後に続く全ての 0 が符号化できそうです。 この時の有意なビット (meaningful bits) は 1011 であると考えられます。

このような性質を利用し、double 値の書き込みは、次のルールに従って行われます。

  • 前の値との XOR が 0 (=同じ値) の場合は 0 を書き込みます
  • 前の値との XOR が 0 でない場合、まず 1 を書き込んだ後に次を計算します
    • meaningful bits が前の値の meaningful bits と同じであれば 0 を書き込んだ後に meaningful bits を書き込みます
    • meaningful bits が前の値と違う場合、1 を書き込んだ後に次の 3 つを順番に書き込みます
      • 先頭の 0 の数を 5bits 表現で書き込みます
      • meaningful bits の長さを 6bits 表現で書き込みます
      • meaningful bits 自体を書き込みます

先ほど同様に、次のような時系列データのブロックを仮定します。

timestamp1,12.0
timestamp2,12.0
timestamp3,24.0

timestamp1 の値は最初の値なのでそのまま書き込まれます(64bits)。 timestamp2 の値は前の値との XOR を取り、同じ値であるので 0 が書き込まれます。

timestamp3 の値は前の値との XOR を取り、違う値であるので 1 を書き込んだ後、 前の値の meaningful bits を確認し、同じではないため 1 を書き込みます。 その後、先頭の 0 のビットの数 (11 個) を 5bits を使って書き込みます。 その後、meaningful bits の長さ (1) を 6bits を使って書き込みます。 最後に、meaningful bits 自体 (1) を書き込みます。この時長さは 1 なので 1 bit になります。

結果として、3 つの double 型の値を書き込むのに、64bits, 1bit, 14bits の合計 79 bits で済んでいます。

仮に、3 つ分の double 値を全て符号化無しで書き込んだ場合は、64 * 3 = 192bits を使用することになるため、 こちらも、大きく符号化することに成功していると言えそうです。

また、この符号化方法も、double 値が近い値で推移するほど符号化効率が良くなる事が重要になっています。

timestamp と value の符号化をまとめた図は次のようになります (Gorilla の論文 Figure 2 から引用)。

f:id:rrreeeyyy:20170525225443p:plain

ただし、これらのエンコーディング方式を用いた場合、時系列データ内のランダムアクセスが不可能になる、といったデメリットもあります。 Gorilla では、上記のように時系列データを符号化し、基本的に全ての時系列データをメモリ上に乗せる事が可能なサイズにすることで、 時系列データのほぼ全てをメモリ上で処理し、処理速度を高速にするといった戦略を取っています。 また、長期間のデータに関しては、別のストレージを用意し、定期的にそちらに書き込むことで、別途参照が可能なようになっているようです。

様々な時系列データベースについて

先ほどは、最近の時系列データベースの象徴であるような Gorilla を例に取り紹介しましたが、 現在開発されているそれぞれの時系列データベースにも様々な特徴があるため、いくつかピックアップして簡単に紹介をします。

Beringei (Gorilla)

Beringei は、先ほど紹介した Gorilla のアイデアをオープンソースで再実装したものです。

オープンソースとして発表された事が最近であるため、Beringei 自体に書き込みをするライブラリがあまりないことや、 読み込みに SQL などの言語を使うことが出来ないことに加え、Gorilla の論文にて紹介されている全ての機能(例えば、長期間のデータの書き出しなど)が実装されていないため、 使用されている例はあまり聞きませんが、今後の動きに注目したい時系列データベースの一つです。

InfluxDB

InfluxDB は、InfluxData 社が開発している Go 製の時系列データベースです。 2013 年頃から開発が進められており、2017/05 時点での最新バージョンは 1.2.4 になっており、安定してきていると言えそうです。

InfluxDB ではタイムスタンプにナノ秒を使用することができ、タイムスタンプ自体のエンコーディング・圧縮には delta-encoding や simple8b 等の方法が使用されています。 書き込む事が出来る値は、Integer, Float, String, Boolean など様々で、Float の符号化には先ほど説明した XOR encodig が使用されていたり、 String に対しては Snappy 圧縮が使用されています。

また、ストレージエンジンの構造として、LSM-Tree を参考に時系列データ用にチューニングした TSM-Tree というデータ構造が使われています。 Storage Engine の章に詳細が書かれているので、興味がある人は読んでみてください。

なお、InfluxDB には Enterprise 版があり、Enterprise 版では Raft を利用して複数ノードで分散して InfluxDB を運用できる事が出来るようになります。 バージョン 0.8 までは OSS 版でも使用できた機能なので、ある程度の実装は公開されており、こちらの実装も興味深いものになっています。

DalmatinerDB

DalmatinerDB は、他の時系列データベースとは少し毛色が違った、Erlang 製の時系列データベースです。 本来は SmartOS 用に最適化されているようですが、Outlayer(旧 Dataloop.IO) 社が Linux 版のメンテナンスをしているようです。

DalmatinerDB は、時系列データベース自体に圧縮の機能はあまりついておらず、Snappy によるデータの圧縮が存在している程度です。 これは、データの圧縮等をファイルシステムで処理させる、という方針を取っているためで、ZFS が推奨のファイルシステムとなっています。

メタデータサーバは時系列データベース自体と分離しており、PostgreSQL が使用されているようです。

DalmatinerDB 用に作られている proxy である ddb_proxy が非常に多くのプロトコルに対応しており、 様々なメトリクス取得ツールからデータを送信できる事が強みの一つとしてありそうです。

また、Outlayer 社のベンチマークでは、他の時系列データベースより書き込みが 2 〜 3 倍程度高速であるという結果が出ていることや、 内部で Riak Core を使用して実装されているため、クラスタリングが行える、といった旨が書かれており、こちらも興味深いデータベースになっています。

Prometheus

Prometheus は厳密には時系列データベースではなく、監視システムそのものですが、 内部で実装されている時系列データベースには、様々な興味深い工夫が施されています。

例えば、時系列データのエンコーディングとして、Gorilla の delta-of-delta encoding や XOR encoding を参考にして作られた、 varbit encoding というエンコーディングが導入されていることや、 時系列データを chunk という 1024 bytes の固定長のデータに分割してメモリ上に保持し、定期的にディスクに書き込む等の方法を使用し、書き込み・読み込みが高速で行えるようになっています。

また、PromQL という Prometheus 上の時系列データを処理するための言語がよく出来ており、様々な時系列データの処理を簡単に行うことが出来るようになっています。

Prometheus そのものは時系列データベースではなく監視ツールですが、監視システムと合わせて使う用途の時系列データベースとしては非常に洗練されている印象があります。

DiamonDB

日本製の時系列データベースとして、株式会社はてなのウェブオペレーションエンジニアである @y_uuk1 さんが作っている、 DiamonDB というものもあります。 こちらはまだ WIP となっていますが、AWS のマネージドサービスと連携して動く時系列データベースは構想として珍しく、 現場で大規模な時系列データベースを実際に運用してきた知見が生きていると推察でき、今後に期待をしています。

その他の時系列データベース

上記で紹介した時系列データベース以外にも、Spotify の作っている Heroic や、 Netflix の作っている atlasHadoop ベースの OpenTSDBなど、本当に様々な時系列データベースがあります。

その他の時系列データベースに関しては、少し古い内容ですが、Outlayer (旧 Dataloop.IO) という会社の Top 10 Time Series Databases という記事並びに、 当該の記事中にある Open Source Time Series DB Comparison というページが非常によくまとまっています。

もし時系列データベースに興味を持たれた方がいたら、上記のページも目を通してみることをおすすめします。

まとめ

時系列データや時系列データベースとは何かというところから、 時系列データベースのエンコーディング手法や、ここ数年間の幾つかの時系列データベースについて紹介しました。

大量のデータ・書き込み・読み込み処理に対して、アーキテクチャやデータ構造の工夫によって改善をしていくのは、 調査していても非常に面白く、普段の業務でも意識して取り組みたい事の一つだと改めて感じられました。 引き続き、内部アーキテクチャやデータ構造を正しく理解しつつ、ミドルウェアの選定・作成を行っていきたいと思います。

参考文献

本記事を書くにあたり、以下の記事・スライド・論文を参考にしました。