開発

宛名印刷ができる年賀状・喪中はがきをリリースしました

はじめに

ラクスルでエンジニアをしている藤田です。
先月、「年賀状・喪中はがき」という商品をリリースしました。
ラクスルで扱っている印刷サービスは基本的に、PDF等でアップロードされた印刷データを対象の商品(チラシや名刺など)に印刷してお客様へお届けするというものです。
今回リリースした商品は宛名印刷という機能があり、印刷データと一緒に宛名リストをアップロードしてもらい、印刷データと共にそれぞれの宛名をはがきに印刷します。他の商品では全く同じ印刷物が注文された部数だけ出来上がるのに対して、宛名印刷では一つ一つの印刷物が宛名の箇所だけ異なる内容になる点が特徴です。
一見するとシンプルに思われるこの機能ですが、実際に開発してみると意外と奥が深く面白かったので紹介したいと思います。

宛名印刷の難しさ

宛名印刷の難しさは「どうやって宛名を違和感なく宛名面にマッピングするか」にあります。組版処理とも呼ばれます。
下の画像を見ていただくと伝わるかと思うのですが、役職・部署の有無や文字数などで宛名面のどこに印刷するかが大きく変わります。
そのため、様々なパターンを考慮する必要があり必然的に開発も難しくなります。

今回はこのよう組版処理を実装するにあたって、開発スピード等を考慮して既成の組版ソフトを利用する方針としました。このソフトはWindows上でしか動作しないため、別途windowsサーバーをたてる必要がありました。

システム概要

少し簡略化していますが、組版処理に関連するシステムの概要図は上記のようになっており、次の通り処理されていきます。上述の組版ソフトは⑥で使用しており、SQSからキューを取得したりS3にアップロードしたりといった周辺の処理はWindowsとも相性が良いGolangで開発しました。

1. ユーザーが印刷データと宛名リスト(CSV)をアップロード
2. 印刷データと宛名リストをS3に保存
3. SQSに組版処理をエンキュー
4. SQSからキューを取得
5. S3から印刷データと宛名リストを取得
6. 組版処理を実施
7. 処理結果ファイルをS3に保存

Webアプリケーションと組版ソフトが動作するWindows Serverを繋げる方法として、Amazon SQSを利用しました。Windows Server上にAPIサーバーをたてる方法もありますが、やや開発コストが増える点と、宛名リストの件数によっては組版ソフトの処理に時間がかかるためキューイングが必要だったこともあり、SQSを採用しました。

マニアックな機能: CIDチェック

今回、開発した機能の中で面白かったものがCIDチェックです。CIDとはアドビ社が定めている文字ごとに一意に振られる番号のことで、フォントの文字を識別するために用いられます。例えば、フォントでは異体字の字形を区別する必要がありますが、Unicode等の一般的な文字コードでは同じコードが割り当てられていることがあるため、CIDが利用されます。
宛名印刷では、宛名に用いられるフォントとして正楷書CB1、リュウミンなど4種類から選択することができます。これらのフォントはカバーしているCIDの範囲以外の文字には使用することができないため、宛名リストで入力された文字が範囲内に含まれているかどうかをチェックすることが必要です。
CIDチェックの実装方法ですが、

1. 入力された文字に紐づくCIDを取得する
2. 取得したCIDが範囲内に含まれるかチェック

という順序でチェックをしていきます。
私が探した範囲ではRubyのライブラリ(CIDチェックはRailsアプリ内で行います)で文字列からCIDを取得するようなものはなかったため、UTF-8のコードとCIDをマッピングしたファイルを作成してUTF-8からCIDを引けるようにしました。
幸い、アドビ社が提供しているcid2code.txtというファイルにCIDと主な文字コードとの対応表がありましたので、このファイルを利用することでマッピングファイルを作成することができました。
細かい話になりますが、最終的に実装は下記のようになりました。

# app/validators/adobe_japan13_validator.rb

class AdobeJapan13Validator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    return if value.nil?
    chars = invalid_chars(value)
    record.errors.add(attribute, :invalid_character, invalid_chars: chars.uniq.join) if chars.present?
  end

  class << self
    def valid_strings_map
      return @valid_strings_map if @valid_strings_map
      @valid_strings_map = {}
      File.open(Rails.root.join('config', 'adobe_japan13.dat'), 'rb') do |f|
        f.each_line do |line|
          line.chomp!
          _cid, utf8 = line.split("\t")
          @valid_strings_map[utf8] = true
        end
      end
      @valid_strings_map
    end
  end

  private

  def invalid_chars(target_string)
    target_string.each_char.reject do |c|
      utf8 = c.unpack1('H*')
      self.class.valid_strings_map.key?(utf8)
    end
  end
end

バリデーターの中で読み込んでいる adobe_japan13.dat がマッピングファイルになっており、次のような内容になっています。左側の数字がCID、右側がUTF-8に対応しています。

# config/adobe_japan13.dat
1	20
2	21
3	22
4	23
5	24
6	25
7	26
8	27
9	28
10	29
11	2a
12	2b
13	2c
14	e28091
# 以下略

おわりに

この記事では宛名印刷という開発案件について紹介しました。
組版処理やCIDチェックといったものは印刷サービスならではで、他の会社ではあまり経験できないラクスルらしいテーマを紹介できたかなと思っています。

そうだ スピードチェック入稿のテストを自動化しよう

ラクスルのサーバサイドエンジニア 加藤です。

今回はスピードチェック入稿(テスト対象が印刷用ファイルの場合)の自動テストについて書いてみたいと思います。

再びスピードチェック入稿とは

チラシや名刺などの印刷をインターネットで注文したことのある方はいらっしゃいますか。

印刷したいものを選んで購入し、自分で用意した印刷データをアップロードして待つと、チラシや名刺などが届きます。通常の通販サイトと違うのは、自分で印刷したいデータを用意し、アップロードする作業です。さらに入稿データはラクスルでチェックし、印刷に適した形式に変換されます。

ラクスルでは、昨年8月末にそれまでオペレータが手動で行ってきたこの工程を自動化、スピードチェック入稿をリリースしました。それまで、1日以上かかってしまうこともあったデータチェックが、その場で完了。印刷物のお届けまでの日数が想定よりかかってしまうということもなくなり、多くのお客様に使われるようになりました。

リリースまでの過程は、スピードチェック入稿リリース秘話でご紹介させていただきました。

スピードチェック入稿のその後

さて、スピードチェック入稿は、その後もどんどん進化してきました。

1. 対応商品の拡大
最初は、チラシ・フライヤーと名刺だけだった対応商品に、ポスター/ポストカード/カード/チラシ折加工/折パンフレットが加わりました。

2. 入稿ファイル形式の追加
入稿ファイル形式も最初はPDFのみでしたが、ai/jpg/png/tiffでも入稿できるようになりました。また、ラクスルで提供しているWEBブラウザから利用できる無料のデザインソフト「オンラインデザイン」で作成していただいたデータも入稿することができます。

3. UXの改善
面裏の入稿原稿向き、折の開き向きなどを実際の印刷物により近い形でご確認していただくために、仕上がりプレビューが生まれました。実際に、ひっくり返したり、開いたり閉じたりして仕上がりを確認することができます。

折加工商品の仕上がりプレビュー

さて、様々な機能追加があると、大変なのがテストです。

ファイルの変換が入るために、テストを自動化しようにも、通常のWebテストのフレームワークだけでは対応できません。悩んでいるうちにも開発は進み、リリースのたびにプロジェクトメンバーがかなりの時間をかけて、データを手動でチェックしてテストをしていました。また、テストの実施もれが発生してしまうことがありました。これでは、チームとして自信を持って開発・リリースすることができません。

テストを自動化するぞ!

なんとかしなきゃとディスカッションしていたところ、「正常リリースで生成された印刷データと変換方法に変更を加えた後に生成した印刷データを、画像に変換して比較したらいいのではないか」というアイデアと、実際にImageMagicのcompareコマンドで検証結果がチーム内でシェアされました。

印刷データ画像

差分なし

差分あり

変換方法を変えて差分ができた場合は、差分箇所が赤く表示されます。これなら、一目で問題に気づけそうです!

このアイデアをとっかかりに、さらに印刷データのファイルに関してテストしたい項目を整理してみました。

1. ファイルの規格、各BOX(*)のサイズ、カラーが注文情報と比較して正しいこと
2. 問題のあるファイルに対して正しくエラーが返されていること
3. 変更前後の印刷データの画像差分がないこと、もしくは差分が妥当であると確認できること

* ドキュメントの用紙サイズ、印刷用の裁ち落としや仕上がりサイズの定義

そして、実際にテストを開発に組み込んでいくために、非エンジニアでも気軽にテストを実施したいと考えました。それぞれテストファイルが30個だとしても、この3項目に対してテストすると3倍の90項目。テストが大変だという理由で改善が進まないのは残念です。

なるべく早く問題に気づけるようにする

早速、設計に取りかかりました。

自動テストの場合は、社内ツールでユーザは自分も含め同じプロジェクトのメンバーです。要件はユーザ向けの機能と違って自由に決められますが、今回は開発がスムーズに進むようにするためなので「開発のなるべく早い段階で問題に気づけるような仕組みを作る」を指針にしました。

スピードチェック入稿のシステムは大きく3つのレイヤーに分かれています。

・フロント:データチェック用のAPIを呼び出し結果を描画
・データチェック用のAPI: フロントから受け取ったリクエストを受けてジョブをキューイング
・バックエンドジョブ:データチェックファイル変換を実施

シンプルにするために、今回の3項目のテストの対象はバックエンドジョブに絞りました。

システム構成

先ほどの指針にしたがって、1. ファイルの規格のテストに関しては、QA環境でスピードデータチェック入稿が使われると必ずジョブ内で自動で実行され、問題が発見されればslackに通知されるようにしました。

 

ファイルアップロード後の処理の流れ

上記の処理の流れの中で、サムネイルの生成が終わったらステータスは終了にして、フロントが描画できるような状態にしつつ、データチェックエンジンのチェック用のスクリプトが走るような作りです。

2. エラーのテスト3. 画像比較テスト に関しては、実行するとしばらくQA環境のジョブを占有してしまうので、実行タイミングをコントロールできるように、手動でslackから実行できるようにしました。

実行するとテストケースのYAMLから、上記の処理のファイル検証〜サムネイル生成を行うジョブをまとめて生成、結果チェックまたは画像比較が順次実行されます。画像比較テストの場合はテストケースが何十個もあるため、期待画像を一括に生成するコマンドも用意。テストケースの更新の手間も軽減しました。

テストの結果も、既存ツールに表示しようかと思いましたが、もう少し要件があったため、以下の画像のように、Datacheck APIの管理画面に表示しています。

画像比較テストの結果一覧(差分がない場合)

 

画像比較テストの結果一覧(差分がある場合)

これで1日〜2日かかっていたテスト作業が、30分以内で実施できるようになりました!
さらにミスもなくなり自信を持ってリリースすることができるように。ファイルの処理で処理フローに変更が必要になって試行錯誤することがあっても、すぐに確認できると開発効率は上がりますし、様々な改善のアイデアも湧いてきます。

自動テストの開発後、スピードチェック入稿当初からやりたかった複雑な処理変更や細かい改善を無事にリリースすることができました。

自動テストを使い続ける

自動テストは、テスト自体のメンテナンスも必要ですね。

今回は同じリポジトリにテストケースの定義を含めたため、通常のWebテストフレームワークと同じように機能修正のPull Requestに含めてテストの変更、追加を行なっています。

自動テストに関するREADMEも用意しメンバーにシェア。エンジニアだけでなく、データチェックのエンジンの設定メンバーも、テストケースの変更・追加を行なって、テストを最新の状態に保っています。

まとめ

スピードチェック入稿の印刷用ファイルを対象にテストを自動化しました。

「開発のなるべく早い段階で問題に気づけるような仕組みを作る」を指針に3つの項目のテストが短時間に実施可能に。これにより、すぐにミスに気づけるようになり、開発効率も向上しました。

テストの自動化は後回しになってきましたが、スピードチェック入稿が進化していく上で重要な施策だったと思っていますし、早速その効果を実感することができました。

ラクスルでは、絶賛エンジニア募集中です。

「仕組みを変えれば世界はもっとよくなる」

ユーザ価値をさらに向上させつつ、より社内外のサービスと繋がっていくプラットホームを開発していきたいエンジニアを募集しています。是非一度オフィスに遊びにきてください!

運用中のRailsプロジェクトをなめらかに複数DB化した話

エンジニアの二串です。

ラクスルのRailsのプロジェクトではデータベースとして Amazon Aurora(MySQL) を採用しています。そしてO/Rマッパーとして当然ActiveRecordを使っています。

さて、ActiveRecordを使っていて悩むのが複数DBの接続ですがみなさんはどうしていますか? ActiveRecordは標準では1つのデータベースにしか接続できないので、複数の異なるデータベースサーバや、マスター・リードレプリカの接続を切り替えるには工夫が必要です。しかし、世の中には素晴らしい方々がいて複数DB切り替えを可能にするgemが提供されています。

今回はそれらgemの中からSwitchPointを採用し、運用中のRailsプロジェクトになめらかに導入したときの経緯と方針、さらに具体設定を紹介します。

確認したバージョンは以下のとおりです

  • Rails 5.1.5
  • Ruby 2.4.2
  • switch_point 0.8.0
  • arproxy 0.2.3

最初からまとめ

記事では以下のことを書いています。

  • 運用中のRailsプロジェクトにSwitchPointを導入し複数DB化しました
  • マスター接続をデフォルトにし、オプショナルでリードレプリカへ接続するようにしました
  • 複数DB化した後も、いままでの素のRails(シングルDB運用)での開発のスピード感を損なわないよう、工夫をしました

導入前の事情

複数DB化の背景を少しだけお伝えしますと、今回のRailsプロジェクトは元々はphpで書かれた管理画面の刷新目的でスタートしたプロジェクトでした(詳しい事情は過去の記事でも触れています)。しばらくの月日の後、プロジェクトがいい感じに育ちまして表側の機能も提供するまでに進化しました。現在では、そうだ、ラクスルを作り直そう!でも触れられているRaksul Platform Projectの1コンポーネントを担っています。

今回の対応はその表側の機能も提供することになったフェーズでの話で、状況は以下のとおりでした。

  • これまで管理画面のみを提供していたので、マスターのみの接続で割り切ってた
  • 今後、raksul.comのパブリックな機能も提供することになった
  • read mostly, write sometimesなサイト特性上、参照系はリードレプリカへ逃したほうがベターだが、マスターに向けてしまっても当面は捌ける規模感
  • とはいえ、マスターの負荷を増加させないようリードレプリカへの接続も用意しておきたい

このような経緯で複数DB化の対応を入れることにしました。

複数DB化によるマイナス面の考慮と導入方針

これまでの経験上、複数DB化することにより以後の開発スピードが落ちたり、運用工数が増えるケースがあることを知っていました。具体的には、

  • 実装工数増加(この save! はマスターに接続して、次はSELECTするからリードレプリカに接続して…と考えたりする工数)
  • コードの見通しが悪くなる(SwitchPointの場合 with_readonly { with_writable { ... } } のようにブロックで囲ってネストするので)
  • テストの実装工数(同上 + FactoryBotで作成する際の考慮等)
  • レプリ遅延の考慮が発生する (INSERT直後にリードレプリカ側でSELECTして空振ったら、マスターにフォールバックして参照する、レプリ遅延を考慮したCI環境にするかどうか、etc..)

等々。

これらのデメリットを受け入れるというのも一つのやり方ですが、そうはしたくありませんでした。なるべく開発スピードを素のRailsでの感覚のまま、これまでのシングルDBオンリーでの開発のスピード感のままに、複数DB化できないだろうか、という点をとても大事にしました。

また、改修にあたっては、既に管理画面向け機能がたくさんあるのでコードの修正範囲は最小にしようとおもいました。

そこで、改修にあたって以下の方針を立てました。

  • gemはSwitchPointを使う
  • マスターDBデフォルト、リードレプリカ参照をオプショナル
  • コントローラのアクション単位で参照を切り替る
  • レプリ遅延を考慮したコードは書かないようにする
  • RAILS_ENV=testではシングルDBで
  • マスター・リードレプリカ接続状況をログに記録する

以下でそれぞれ詳細説明します。

SwitchPoint

SwitchPoint 1択でした。理由は、私の前職のプロジェクトで使っていて問題なく動いているのを知っていたのと、そのときに内部実装を大体把握していたからでした。よって他のgemは検討しませんでした。

マスターDBデフォルト、リードレプリカ参照オプショナル

SwitchPointのREADMEを読み進めると、モデルクラスはマスター、リードレプリカどちらに接続するかを with_readonly {} または with_writable {} ブロックでどちらも指定した例に見られます。この方針で進めると、我々の場合既存の管理画面のコントローラをすべて修正しなければならなくなってしまいます。コードの改修量は最小にしたかったのでこれは避けたい。

そこで、まず、with_readonly {}with_writable {} も指定せずにActiveRecordでクエリを実行した場合はデフォルトでマスターに接続されるようします。そして重いクエリが実行されるページやアクセスが多いページでは都度 .with_readonly {} を使ってリードレプリカへ接続させるようにしました。

# こういう処理が既にあって...
Order.find(params[:id]).update!(order_params)

# 素で SwitchPoint を導入すると以下のような書き換えが必要だが...
order = nil
order = Order.with_readonly { Order.find(params[:id] }
Order.with_writable { order.update!(order_params)

# そうではなくマスター接続をデフォルトにすれば、既存コードを書き換えずに済む
Order.find(params[:id]).update!(order_params)

これを実現するにはいくつか設定が必要です。READMEにはあまり書かれていなかったので内部実装も読んでます。

database.yml

# writable 系は Rails 標準のネーミング development, production, etc とする.
# これは https://github.com/eagletmt/switch_point/issues/16 の通りで、標準のネーミングの設定が無いと
# Rails が起動しないケースに遭遇したため.
development:
  # 接続情報(略)
  database: raksul_development
development_raksul_readonly:
  # 接続情報(略)
  database: raksul_development

test:
  # 接続情報(略)
  database: raksul_test
test_raksul_readonly:
  # 接続情報(略)
  database: raksul_test

production:
  # 接続情報(略)
production_raksul_readonly:
  # 接続情報(略)
  • マスターの接続情報はRails標準のdevelopment,test,productionに定義する
  • リードレプリカの接続情報は#{Rails.env}_raksul_readonly に定義する

switch_pointの設定

SwitchPointでマスターDBへの接続をデフォルトにするには SwitchPoint.writable!(接続シンボル名)をアプリケーション初期化フェースでcallします。

# config/initializers/switch_point.rb

SwitchPoint.configure do |config|
  raksul_config = {
    readonly: :"#{Rails.env}_raksul_readonly",
    writable: :"#{Rails.env}"
  }
  if Rails.env.test?
    # 通常SwitchPointは2本コネクションを作る(readとwrite).
    # しかし、database cleanerでtransaction strategyを使っているとテストがfailする.
    # なぜなら、transactionのbeginはwriteコネクションでcallされ、
    # SELECT は read コネクションで呼ばれるが、
    # FactoryBotで作られたレコードはcommitされるまでSELECTしても参照できないのでテストが成立しない.
    #
    # この問題を解決する2つの方法:
    #   1. RAILS_ENV=testでのみSwitchPointのコネクションを1本にする
    #   2. transaction以外のstragegy(truncation or deletion)に変更する
    #
    # 我々は1を選択した。2の方法ではテストが遅くなったため。
    #
    # 1をやるには、readonlyのコネクション設定を消すことで実現できる.
    # こうするとSwitchPointはwritableコネクションにフォールバックする挙動
    # ref https://github.com/eagletmt/switch_point/blob/v0.8.0/lib/switch_point/proxy.rb#L131
    raksul_config.delete(:readonly)
  end
  config.define_switch_point :raksul, raksul_config
end
# Change @global_model of the proxy for raksul :writable
# ブロック指定なしの場合の挙動を writable にする
SwitchPoint.writable!(:raksul)


# app/models/application_record.rb
class ApplicationRecord < ActiveRecord::Base
 self.abstract_class = true

 # モデルのSwitchPoint組み込み
 use_switch_point :raksul
end

なお、一点database_cleanerでtransaction strategyを使っていたので上のコメントの通りコネクションを1本にする対策を入れました。

これで既存のコードは修正せずに済みます。

ではリードレプリカを参照したい場合には with_readonly { } のブロックを書かなければならないのか? これも次の方法で楽をします。

コントローラのアクション単位でリードレプリカに切り替える

開発ポリシとして、コントローラのアクション単位でリードレプリカへ接続を向けるようにします。

例えば、OrdersControllerの #index, #show, #new, #edit ではDBへの書き込みはなく参照しか発生しない、というケースは良くあることかとおもいます。なので、around_action filter を使って with_readonly {} をcallしてあげます。そうすることで、リードレプリカ参照においても with_readonly {} のブロックを意識することなく filter を設定するだけで済みます。ブロックがないのでコードの見通しが損なわれません。

class ApplicationController < ActionController::Base
  private

  def with_readonly
    ApplicationRecord.with_readonly { yield }
  end
end

class OrdersController < ApplicationController
  around_action :with_readonly, only: %i[index]

  def index
    # アクション内で .with_readonly { .. } を意識しなくて済む
    @orders = Order.all.order(:id)
  end
end

中には参照系のペーシだけど別途行動ログを書き込みたいといった場合もあるかもしれませんが、そういうケースではそのそのアクションではリードレプリカへ接続させずマスターへ接続させる、で割り切ります。

レプリ遅延は考慮しないコードを書く

1つのアクション内でいくつかレコードをSELECTしINSERT or UPDATEする時、理想的には参照はリードレプリカへ、書き込みはマスターへ、と細かく切り替えるのがDB負荷を考えると理想的です。ただ、レプリ遅延により書き込み直後のリードレプリカ側のSELECTが空振って想定してなかったバグが発生したり、またその対策としてマスターへフォールバックさせるコードを書いたり…という経験がある方もいるとおもいます。このような状況では開発工数も運用工数も増えます。

そう、この考慮したくない、そうおもいました。ですので思い切って割り切ることにしました。つまり、書き込みが発生するアクション内ではずっとマスターと接続させておく。こうすることでレプリ遅延しても同じアクション内でレプリ遅延は発生しないので考慮する必要はなくなります。(リダイレクト先のアクションでレプリ遅延がある可能性はありますが)

トラフィック特性上、更新系のアクションをマスターに向けても即座に詰まることはないので、これで良いと思っています。もし、トラフィックが激増して厳密に切り替えないと回らない…という状況になったら対策するとして、そうなったときはつまりサービスが拡大しているということなのでとても嬉しい状況ですね。

RAILS_ENV=testではシングルDBで

上述の通り、レプリ遅延を極力考慮しない割り切りなので、テスト実行においてレプリ遅延が発生するケースをあぶり出すような考慮はしません。ですのでCI環境やローカル環境ではシングルDBなのでレプリケーション設定もしてません。

マスター・リードレプリカとの接続状況をログに記録する

開発時に便利なので、ActiveRecordのクエリログに readonly or writable どちらに接続したかを記録するようにしました。ログの拡張には cookpad/arproxy を使いました。とても便利で感謝しかないです。

設定

# config/initializers/arproxy.rb

if Rails.env.development? || Rails.env.test?
  require 'switch_point_logger_enhancement'

  Arproxy.configure do |config|
    config.adapter = 'mysql2'
    config.use SwitchPointLoggerEnhancement
  end
  Arproxy.enable!
end

# lib/switch_point_logger_enhancement.rb

class SwitchPointLoggerEnhancement < Arproxy::Base
  def execute(sql, name = nil)
    proxy = SwitchPoint::ProxyRepository.checkout(:raksul)
    mode = proxy.mode
    name = "#{name} [#{mode}]"
    super(sql, name)
  end
end

 

ログサンプル

SCHEMA [readonly] (0.8ms)  SHOW FULL FIELDS FROM `tickets`
Ticket Load [readonly] (0.3ms)  SELECT `tickets`.* FROM `tickets` WHERE `tickets`.`staff_id` IN (100, 201, 12, 13, 71, 10)
Staff Load [writable] (0.3ms)  SELECT  `staffs`.* FROM `staffs` WHERE `staffs`.`id` = 2 ORDER BY `staffs`.`id` ASC LIMIT 1
Role Load [writable] (0.4ms)  SELECT `roles`.* FROM `roles` INNER JOIN `abilities` ON `roles`.`id` = `abilities`.`role_id` WHERE `abilities`.`staff_id` = 2

[readonly] [writable] の箇所です。

まとめ

運用中のRailsプロジェクトにSwitchPointを導入し複数DB化しました。

マスター接続デフォルト、リードレプリカ接続をオプショナルとすることで、既存コードの改修を最小に押さえて導入の敷居を下げつつ、リードレプリカを参照させるときはコントローラのアクション単位で制御するようにしました。

また、レプリ遅延の考慮は極力意識しなくて済むよう、マスター、リードレプリカの接続を混ぜるアクションを実装しない割り切りをしました。

これらにより、複数DB化した後も、素のRails(シングルDB運用)と同じレベルの開発スピード感を維持することができました。

実際、本番導入からしばらく立ちますが問題なく運用できており、また開発もこれまでどおりのスピード感で進めれています。

ラクスルではエンジニアを積極採用しています

いろいろ詳しく書きましたが、複数DB化にあたっての検討は私一人で行ったわけではなく、自社のサービス傾向や開発運用スタイル似合うかどうかを、周りにいるRailsに詳しいエンジニアにも相談しながら、進めていきました。1人で決めるより話し合って決めるラクスルのスタイルはとてもやりやすく感じています。

そういうわけでして、ラクスルでは私達と開発指針を議論しながら開発したいエンジニアを絶賛募集しています。是非一度オフィスに遊びにきてください!

【Ruby】Array から Hash を作る方法7選(a.k.a. やっぱり Array#zip はかわいいよ)

ラクスルでサーバサイドエンジニアをやっている小林です。

最近の業務では、主に Ruby を書いています。

さて、Ruby の組み込みライブラリにはいろいろな便利メソッドがありますが、
みなさん推しメソッドはありますか?

個人的推しメソッドは Array#zipHash#transform_values です。

Hash#transform_values について少し紹介すると、
もともと Rails4.2 の ActiveSupport で実装され、
Ruby2.4 で組み込みライブラリに移植されました。
移植の際は、名前をどうするかという議論でとても盛り上がったようです。
また、Ruby2.5 からは姉妹メソッドとも言える Hash#transform_keys が実装されました。

Hash#transform_values の話はこの辺にして、今回は Array#zip の推しポイントを紹介するため、
Array から Hash を作る方法について考えてみようと思います。

コーディングをしていると、下記のようなコードを書きたいことはないでしょうか?

  • ActiveRecord で取ってきて、id をkey、インスタンスを value にしたHash を作りたい
    • 例) [AR1, AR2, …] ⇒ { id1: AR1, id2: AR2, … }
  • 文字列のArrayに対し、元の文字列をkey、正規化後の文字列を value にしたHash を作りたい
    • 例) [Str1, Str2, …] ⇒ { Str1: NormalizeStr1, Str2: NormalizeStr2, … }

このようなときの実装方法をいくつかあげ、後半で性能比較をしてみようと思います。

 

以下、ActiveRecord で User 一覧を取得し、id を key、インスタンスを value とするHash を作成する場合を考えます。

空Hashに追加していく

他の言語でも実装できる、一番オーソドックスな方法かと思います。

array = User.all
hash = {}
array.each do |user|
  hash[user.id] = user
end
hash

 

Array#to_h を利用する

Ruby 2.1 から Array#to_h というメソッドが追加になっています。

レシーバを[key, value] のペアの配列として、Hash を返します。

これを利用すると、下記のように書くことができます。

array = User.all
array.map { |user| [user.id, user] }.to_h

 

Array#zip & Array#to_h を利用する

[key, value] のペアを作るのであれば、 Array#zip が便利です。

メソッドチェインですっきりと書けるところが、個人的気に入っています。

これだけでも、Array#zip がかわいいと思えます。

array = User.all
array.map(&:id).zip(array).to_h

 

Array#transpose & Array#to_h を利用する

レシーバを二次元配列として、転置配列を作成する Array#transpose を利用しても、
同じことができます。

array = User.all
keys = array.map(&:id)
[keys, array].transpose.to_h

 

Enumerable#each_with_object / Enumerable#inject を利用する

Array#to_h がない時代は Enumerable#each_with_objectEnumerable#inject を使うことが
多かった気がします。

array = User.all
array.each_with_object({}) do |user, hash|
  hash[user.id] = user
end

 

Enumerable#index_by を利用する(ActiveSupport)

よくあるパターンなので、ActiveSupport に Enumerable#index_by という、
まさになメソッドがあります。

ただ、こちらは Proc の返り値を key とする Hash を返すので、Array の要素を key、
Proc の返り値を value とする Hash を作りたい場合は、Hash#invert で一手間加える必要があります。

array = User.all
array.index_by(&:id)

 

Enumerable#reduce & Hash#merge を利用する

Lisp 的な発想で、 Enumerable#reduce と Hash#merge を使って畳み込みを行うことで 、
Hash を作ることもできます。

ちなみに、Ruby の Enumerable#inject とEnumerable#reduce は違う名前ですが、
同じ挙動をします。

少し話がそれますが、なぜ同じ挙動で名前が違うメソッドがあるのかについては、
るびまに書かれているので、読んでみると面白いかもしれません。

array = User.all
array.map {|user| {user.id => user} }.reduce(&:merge)

 

比較

みなさん、どの方法で実装することが多いでしょうか?

好みやコードの読みやすさなどで意見が分かれそうですが、一指標として、
各実装方法の性能評価をしてみたいと思います。

今回は、Array から Hash に変換する性能のみを評価するため、変換やメソッド呼び出しはせず、
Array から key と value が同じ Hash に変換する場合の性能を比較してみようと思います。

検証コード

ベンチマークの取得には、 Ruby on Rails Guides にも紹介されている
benchmark-ips gem を利用したいと思います。

検証コードは以下のとおりです。

#!/usr/bin/env ruby

require 'active_support/all'
require 'benchmark/ips'

array = (1..10_000).to_a

Benchmark.ips do |r|
  r.config(time: 20)

  r.report "Empty Hash" do
    hash = {}
    array.each do |num|
      hash[num] = num
    end
    hash
  end
  r.report "to_h" do
    array.map { |num| [num, num] }.to_h
  end
  r.report "zip & to_h" do
    array.zip(array).to_h
  end
  r.report "transpose & to_h" do
    [array, array].transpose.to_h
  end
  r.report "each_with_object" do
    array.each_with_object({}) do |num, hash|
      hash[num] = num
    end
  end
  r.report "index_by" do
    array.index_by { |num| num }
  end
  r.report "reduce & merge" do
    array.map { |num| {num => num} }.reduce(&:merge)
  end

  r.compare!
end

実行環境は以下のとおりです。

ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin16]
activesupport (5.1.4)
benchmark-ips (2.7.2)

 

結果

Warming up --------------------------------------
          Empty Hash    80.000  i/100ms
                to_h    73.000  i/100ms
          zip & to_h   108.000  i/100ms
    transpose & to_h    98.000  i/100ms
    each_with_object    70.000  i/100ms
            index_by    63.000  i/100ms
      reduce & merge     1.000  i/100ms
Calculating -------------------------------------
          Empty Hash    773.943  (±10.3%) i/s -     15.280k in  20.013161s
                to_h    733.483  (± 8.9%) i/s -     14.600k in  20.090466s
          zip & to_h      1.065k (±10.3%) i/s -     21.060k in  20.027320s
    transpose & to_h      1.005k (± 8.5%) i/s -     19.992k in  20.067946s
    each_with_object    719.383  (± 7.1%) i/s -     14.350k in  20.063602s
            index_by    654.471  (± 8.6%) i/s -     12.978k in  19.999714s
      reduce & merge      0.962  (± 0.0%) i/s -     20.000  in  20.834702s

Comparison:
          zip & to_h:     1065.3 i/s
    transpose & to_h:     1004.8 i/s - same-ish: difference falls within error
          Empty Hash:      773.9 i/s - 1.38x  slower
                to_h:      733.5 i/s - 1.45x  slower
    each_with_object:      719.4 i/s - 1.48x  slower
            index_by:      654.5 i/s - 1.63x  slower
      reduce & merge:        1.0 i/s - 1107.19x  slower

Array#zip 早いですね!!メソッドチェーンですっきりかける上、処理も早いという、
これは推さざるをえない感じがしませんか?

Array#transpose も Array#zip とほぼ同じくらいの性能ですが、
やはり個人的にはメソッドチェーンで書ける Array#zip のほうが好きですね。

他の手法についても見てみると、Enumerable#index_by が思ったより遅いです。
実装を見たところ、空Hashに追加していく実装と同じなので、
yield の呼び出し分オーバーヘッドがかかっている感じでしょうか。

Enumerable#reduce と Hash#merge を利用する方法は、
配列長分 Hash#merge が実行されるため、かなり遅くなっています。

 

ただ、実際のコードでは、key と value が同じということはなく、
key や value に対して何かしらの処理を行うため、Hash の作成コストより、
他の処理のオーバーヘッドが大きくなります。

別途、key を Integer#to_s して Hash を作成する場合のベンチマークも取ってみましたが、
空Hash に追加する方法が一番早く、Enumerable#reduce & Hash#merge を除く
実装方法については、それほど変わらないという結果になりました。

#!/usr/bin/env ruby

require 'active_support/all'
require 'benchmark/ips'

array = (1..10_000).to_a

Benchmark.ips do |r|
  r.config(time: 20)

  r.report "Empty Hash" do
    hash = {}
    array.each do |num|
      hash[num.to_s] = num
    end
    hash
  end
  r.report "to_h" do
    array.map { |num| [num.to_s, num] }.to_h
  end
  r.report "zip & to_h" do
    array.map(&:to_s).zip(array).to_h
  end
  r.report "transpose & to_h" do
    [array.map(&:to_s), array].transpose.to_h
  end
  r.report "each_with_object" do
    array.each_with_object({}) do |num, hash|
      hash[num.to_s] = num
    end
  end
  r.report "index_by" do
    array.index_by(&:to_s)
  end
  r.report "reduce & merge" do
    array.map { |num| {num.to_s => num} }.reduce(&:merge)
  end

  r.compare!
end

=begin
Warming up --------------------------------------
          Empty Hash    17.000  i/100ms
                to_h    15.000  i/100ms
          zip & to_h    19.000  i/100ms
    transpose & to_h    18.000  i/100ms
    each_with_object    19.000  i/100ms
            index_by    18.000  i/100ms
      reduce & merge     1.000  i/100ms
Calculating -------------------------------------
          Empty Hash    192.959  (± 8.8%) i/s -      3.825k in  20.060582s
                to_h    178.314  (± 9.0%) i/s -      3.525k in  20.023982s
          zip & to_h    181.005  (±10.5%) i/s -      3.572k in  20.065550s
    transpose & to_h    176.782  (± 9.1%) i/s -      3.510k in  20.039329s
    each_with_object    192.932  (± 5.2%) i/s -      3.857k in  20.054975s
            index_by    182.739  (± 4.4%) i/s -      3.654k in  20.036235s
      reduce & merge      0.905  (± 0.0%) i/s -     19.000  in  21.030102s

Comparison:
          Empty Hash:      193.0 i/s
    each_with_object:      192.9 i/s - same-ish: difference falls within error
            index_by:      182.7 i/s - same-ish: difference falls within error
          zip & to_h:      181.0 i/s - same-ish: difference falls within error
                to_h:      178.3 i/s - same-ish: difference falls within error
    transpose & to_h:      176.8 i/s - same-ish: difference falls within error
      reduce & merge:        0.9 i/s - 213.18x  slower
=end

ちなみに、空Hash に追加するという Enumerable#index_by の実装も、
リファクタリングされて現在の形になっています。

まとめ

コーディングの際よくあるパターンとして、Array から Hash を作成する実装方法を7つあげ、
性能比較をしてみました。

個人的推しメソッドである Array#zip のかわいさが少しは伝わったでしょうか?

 

iframe で複数の管理画面を1つの統一されたサイトに見せるパターンのまとめ

こんにちは。エンジニアの二串です。普段はサーバサイドの開発をしていますが、今日は最近仕事で取り組んだフロントよりの話になっています。

iframe を使って複数の管理画面サイトをあたかも1つの統一されたサイトとして見せるパターンをまとめます。

iframe を使って別サイトをはめ込むことは簡単ですが、実際複数ページあるサイトをはめ込もうとすると、ただ iframe を使うだけでは力不足です。例えばiframe内でのページ遷移、高さ調整、パーマリンク等で問題を感じます。

今回紹介する tips のいくつかはインターネット上で見つけられますが、今回の複数管理画面を1つにマージするという視点でまとまった記事は見つけられなかったので、まとめたら便利なのではとおもい記事にまとめました。

コードスニペットを以下で掲載していますが、より詳しくはデモアプリも併せて見ていただければとおもいます。

背景

移行イメージ

ラクスルに存在する最もレガシーなシステムは admin と呼ばれるいわゆる管理画面です。PHPで作られています。そのレガシー管理画面を素早く新システム(Ops Rails製)へ移行する必要がありました。

当時の状況としては

  • 新管理画面はまだ機能が少ないが、今後の新規開発は新管理画面でしたい
  • 旧管理画面には多くの機能がまだあり、理想的には新管理画面に移植したいものの、工数的にさくっと移行できない
  • オペレーションの中心は旧管理画面から新管理画面に移行してしまいたい

というような状況でしたので、iframe を使って新管理画面の1機能として、旧管理画面の各ページを埋め込んでしまって、ユーザー目線での移行については少ない工数で完了させることにしました。

iframe埋め込みによる問題点

単に iframe の src 属性に URL を指定すると、以下の点が課題になります。

  • 旧管理画面のページ数は多いので、ページごとに iframe を設置するのは大変
  • iframe の高さ動的に変えれない(初期ページや子側でページ遷移した場合)。結果的にページが切れる
  • ブラウザアドレスバー問題
    • 子側でページ遷移を何回かした後に F5 を押すと元に戻る。またURL を他の人にシェアできない。
  • 子側ページ内のリンクが 旧管理画面URL 問題
    • リンク先 URL を Slack 等でシェアできない(できるけど iframe が外れる)
    • 別タブで開くと iframe が外れる
  • そもそも、デザインの統一性がない(子側のヘッダやサイドバーメニューが邪魔)

さらに補足すると、今回の2画面はドメインが異なるため、iframeの親・子間で window をまたいで javascript や css で操作しようにもクロスドメイン(CORS)のため DOM 操作できません。

仕組み全体像

以上の問題を踏まえ、以下の指針を立てました

ページ表示の流れ

  • 新管理画面側(Rails)では `GET /proxy?path=path/to/page` というエンドポイントを作り <iframe src=”https://旧管理画面/path/to/page”> をレンダリングする。つまりどんなページもはめ込むことができる。
  • 親・子それぞれに今回のための javascript  を設置し(parent.js, child.js)、window間通信は window.postMessage() API を使う。これによりクロスドメインであってもwindow間で通信可能
  • この通信路を使って子の page height などを 親に伝える。高さ以外の情報もあるので、メッセージタイプ(type)、メッセージデータ(data)を含めた object をデータペイロードに入れて送ることにする。
  • iframe内のリンクの諸々の問題は、a タグの href の値を力技で新管理画面のproxy URL に書き換える。
  • サポートブラウザは Google Chrome のみとする。社内利用のツールなので工数削減も踏まえ割り切れる点と、そもそも社内で Google Chrome が標準で使われているので。

以下、長くなりますが、1つずつ見ていきます。

GET /proxy?path= エンドポイント

# app/controllers/proxies_controller.rb
class ProxiesController < ApplicationController
  def show
    path = params[:path] || ''
    @src = 'https://旧管理画面FQDN/' + path
  end
end

# app/views/proxies/show.html.erb
<iframe id="proxy-iframe" src="<%= @src %>" height="1024" style="overflow: hidden; border: none;" scrolling="no" frameborder="no"></iframe>

# config/routes.rb
get '/proxy', to: 'proxies#show'
  • GETパラメタの path から旧管理画面の URL を構築し iframe の src 属性へセット
  • height=”1024″ は初期値として。後述の方法で別途ページ毎に動的に変える。
  • その他、iframeのボーダー枠線。スクロールバーを消す。これはiframeっぽさを無くすための工夫
  • id属性 `proxy-iframe` は後述の javascript の処理で利用

これで旧管理画面の任意のページを新管理画面で扱えるようになりました。

なお、旧管理画面側が X-Frame-Options を返却していたので iframe 内で表示させるため nginx で消しこみました。

親・子window間通信

新・旧管理画面それぞれに以下の javascript を置きます。今回のケースでは、子から親に一方通行でメッセージを伝え親側でアクションさせればよかったので、子と親の通信はいわゆるクライアントサーバモデルになっています。

子側

const postMessage = (type, data) => {
  const rawData = JSON.stringify({ type: type, data: data })
  window.parent.postMessage(rawData, '*')
}

// iframe内でレンダリングされた場合にのみ発火させる
if (window !== window.parent) {
  window.addEventListener('load', () => {
    // 子の高さを親に伝え、親の iframe の heigit を変更
    postMessage('PageHeight', {height: document.body.scrollHeight})
  }, false)
}
  • iframe 内でレンダリングされた場合にのみ実行している
  • on load 時に高さを送る。メッセージには type と data がありJSON シリアライズして送る。

iframe 内でレンダリングされた場合にのみこの仕組が発動するようにすることで、移行をやりやすくしました。旧管理画面直アクセスでは発動しないので、旧管理画面直アクセスへのパスを残しつつ、緩やかに移行を進めれます。

親側

const messageHandlers = {
  PageHeight: (data) => {
    // iframe の height を調整
    let elm = window.document.getElementById('proxy-iframe')
    elm.style.height = `${data.height}px`
  }
}

window.addEventListener('message', (event) => {
  console.log('[ops] message received', event)

  // On development environment webpack-dev-server sends message, so skip message from it.
  if (/^https?:\/\/(localhost|127.0.0.1)/.test(event.origin)) return

  // Verify received message from for security manner of postMessage() API,
  const originRe = /旧管理画面URL/
  if (event.origin.search(originRe) === -1) {
    console.log('Blocked the message from ' + event.origin)
    return
  }

  const data = JSON.parse(event.data)
  if (data.type === null) throw new Error('[ops] Message received, but no type specified')
  if (!messageHandlers.hasOwnProperty(data.type)) {
    throw new Error(`[ops] Message received, but type "${data.type}" is invalid`)
  }
  messageHandlers[data.type](data.data)
})

細かいエラーハンドリングも載せましたが、中心は以下のとおりです。

  • window.postMessage() で送信されたデータは ‘message’ イベントで受け取れる
  • type に対応するメッセージハンドラ関数へディスパッチする
  • PageHeight ハンドラでは iframe の height 属性を変更

iframe高さの動的調整

1つ前のセクションのとおりです。

ブラウザアドレスバー問題

iframe内でページ遷移を繰り返してもブラウザアドレスバーのURLは最初のURLのまま問題。実際のカスタマーサポートなどの現場では、「あ、この注文、サポートが必要そうだから Slack で注文詳細のURLをシェアしておいて…」 といったことありますので、iframe内で遷移したあとの URL も気軽に貼り付けれる必要がありました。

そこで、子の a タグのクリックイベントを prevent default  で止めて、PageMove メッセージを送り、親側windowでページ遷移させてしまうことにしました。詳しくはサンプルアプリのコードを参照ください。

なお、a タグ以外に POST 等の後のサーバサイドでのリダイレクト処理される場合にも同様の課題はあります。管理画面の特性を検討した結果、リダイレクトについては特に何も対策せずとも運用上なんとかなると判断してます。

子側ページ内のリンクが 旧管理画面URL 問題

リンク先をシェアされたり、別タブで開こうとすると iframe が外れてしまう。

これに対しては、子側の DOMContentLoaded で hrefの属性値を 新管理画面の proxy URL に挿げ替えてしまうことにしました。

const fakeAnchors = function () {
  document.querySelectorAll('a').forEach(function (elm) {
    // getProxyUrlFromAdminUrl() は https://旧管理画面FQDN/foo/bar を
   // https://新管理画面FQDN/proxy?path=foo/bar に変換
    elm.href = getProxyUrlFromAdminUrl(elm.href)
  }
}

// iframe内でレンダリングされた場合にのみ発火させる
if (window !== window.parent) {
  // ...
  window.addEventListener('DOMContentLoaded', function () {
    // ...
    fakeAnchors()
  }, false)
}

なお、javascript を使わず、旧管理画面の view の各aタグを手で全て書き換える方が素直ですが、そうしなかった理由は、数が多いのと、暫くの間旧管理画面にダイレクトにアクセスできるパスは残しておきたかったためです。管理画面だから許される力技…です。

ページ内リンク問題

<a href=”#foo”>foo</a> のようなリンクです。iframe のオプションで scrolling=”no” している、また href をすげ替えた都合でスクロールしてくれないので、このようなリンクがクリックされた場合は、子から親に要素のポジションを計算して親側でスクロールさせるようにしました。詳細はサンプルコードを…といいたいところですがこの部分サンプル書けてないです :pray:

なお、production のコードではこの部分も window.postMessage() で 親にスクロール位置を通知させました。

ヘッダ・サイドバー消し

新管理画面の吸収されてしまった旧管理画面。もう旧管理画面のヘッダやサイドバーメニューは不要なので消します。旧管理画面側で DOMContentLoaded のタイミングで 追加の css ファイルを入れて、消し込むことにしました。

子側

const applyOpsCss = function () {
  const style = document.createElement('link')
  style.rel = 'stylesheet'
  style.href = '/css/additional.css'
  document.getElementsByTagName('head')[0].appendChild(style)
}


// iframe経由でのみ発火させる
if (window !== window.parent) {  
  applyOpsCss()
  window.addEventListener('DOMContentLoaded', function () {
    postMessage('PageDOMContentLoaded', {})
  }
}

  • iframe内でレンダリングされた場合に限り additional.css を適用する。additional.css 内では消したい要素に display: none; を適用している
  • DOMが読み込まれたら親に通知(次を参照)

親側

const messageHandlers = {
  // ...
  PageDOMContentLoaded: (_data) => { window.document.getElementById('proxy-iframe').style.visibility = 'visible' },
  // ...
}
  • スタイルを当てるまでの非常に短い間はヘッダ等が見えてしまうので画面がチラつく。これを防ぐために ngCloak 的なアプローチ、すなわち、iframe に `visibility : hidden;` で予め非表示にしておいて、追加のスタイルが適用されたら PageDOMContentLoaded メッセージを送信しiframe のdisplay visibility を `visible` に変更する

CORS でなければ親側だけで iframe 内の load を検知できそうな気はするのですが、CORS だったのでこのようにしました。

メニューのマージ

このタイミングでメニューバーを整理しました。新・旧それぞれのメニューバーにあった項目を整理し、新管理画面のメニューバーにマージしました。格段に見やすくなってこちらは評判です。

まとめと所感

iframe を使って複数の管理画面サイトをあたかも1つの統一されたサイトとして見せるパターンをまとめました。特に CORS 環境おいては window.postMessage() API を利用することで様々な課題を解決することができました。

この方式で本番運用して4ヶ月ほど立ちますが、大きなトラブルなく稼働できています。管理画面という特性上そのあたりは柔軟に対応できているのと、対応ブラウザを Chrome 1本に割り切ったので、導入後のメンテ工数は今のところほぼなく上手く動いてます。

本番の切り替えについては、旧画面と内容は変わらないので、導入調整コストがほとんどかからず、また利用者=オペレーターさん達の心理的負荷や学習コストも低く抑えることができました。これは本アプローチの最大のメリットではないかとおもいます。

ちなみに、このアイデアを思いついた翌週が運良く Hack It Day だったので、1日つかってプロトタイプを作って、どのあたりに技術課題があるか、工数感などつかむことができたのが良かったとおもいます。 * Hack-It Dayは月に一度、ラクスルのエンジニアが自由に開発することができる日)

さて、長くなりましたが最後までお読み頂きありがとうございます!!

ラクスルでは、絶賛エンジニア募集中です。
「仕組みを変えれば世界はもっとよくなる」
世界が変わっていく瞬間を一緒に体験したいエンジニアの方、お待ちしています☆

そうだ、ラクスルを作り直そう!

10月からラクスルにジョインさせていただいた水島です。

新参者ですが、宜しくお願いいたします。

さて、入社して間もなくCTOの肝いりでスタートした 「Raksul Platform Project」 のプロマネを拝命したため、今日はその全体感の話をしたいと思います。

なにをするのか

「スタートアップあるある」だなんて言わないでください。

ラクスルをフルスクラッチで作り直そうとしています。

でもそれはあくまで手段です。

目的は、

  • 技術負債と思われている部分を根本的に解消して開発しやすい状態にする(エンジニアを幸せに)
  • システムに柔軟性を持たせて経営戦略の選択肢が増えている状態にする(経営を幸せに)

の大きく2つです。

特に前者の「エンジニアを幸せに」という目的に対する経営陣の温度感が不思議と高いのはポジティブに感じています。短期的な投資対効果とかではなく、「ものづくり」を大切にする会社になるんだという意思が強く感じられるので、長い道のりにはなりそうですが、エンジニアとデザイナーがさらに輝けるようにするために是非やりきりたいと思っています。

後者の「経営を幸せに」という目的は、プロマネである私のバランサーとしてのプライドみたいなものです。ただ作り直してキレイになりました、幸せです!だけでは虚しさがあるので、経営の潜在ニーズを今回のプロジェクトで一定先回りして、いつかドヤ顔したいと思っているのです。

つまりは、単純に他言語、他フレームワークで作り直すということではなく今後のアーキテクチャーから見直していくプロジェクトです。

 

今までのいろんなアンチパターンを思い返して方針を考える

ラクスルの現在のシステムの状態を見たり、私が今まで経験してきた様々なサービス、プラットフォーム、受託システムの開発を思い起こすと、やってはいけないアンチパターンの連続が強烈な反省と共に頭の中を駆け巡ります。

それらをベースに今回はどのようなアーキテクチャーで進めていこうとしているかをいくつかご紹介したいと思います。

アンチパターン1: サービスのコア機能が汎用化されていない

サービスはユーザーのニーズや市場環境を見ながら進化していくものなのですが、再利用可能なコア機能が主力サービスの中に閉じ込められていることがあります。

私の経験を思い返しても、

  • 会員体系の認証、認可機能
  • 決済、経理、資金決済法遵守のための仮想通貨管理などの機能
  • データ分析基盤機能
  • 校閲、投稿内容チェックなどの機能
  • 画像管理、変換機能
  • CMSと広告配信管理機能
  • ファイルシステムみたいな機能

などがありました。

つまりは社内外で今後再利用される可能性があるものを主力のサービスとは疎結合に作っておけばよかったと後悔し、後で掘り起こして、汎用サービス化することを繰り返してきました。

社外のクラウドサービスで置き換え可能な機能も増えているので、要件がほぼフィットするならそれらを活用すべきというのは言うまでもなく、実際にFirebaseなどに載せ替えた部分もありましたが、自社の強みや特殊要件が眠っている場合は、早めの段階で社内クラウドサービスのように汎用的な設計にして再利用可能な状態にしておくべきです。

現在のラクスルにおいて、主力サービスの中に閉じ込められている汎用的なコア機能としては、

  • ラクスル社の他事業(ハコベル事業等)で共通に使える汎用機能レイヤー
    • 個人向け、法人向け決済、経理処理などの機能
    • メール送信とテンプレ管理機能
  • 印刷関連事業で共通に使える汎用機能レイヤー
    • 印刷SCMと発注基盤機能
    • スピードチェック入稿を含むDTP機能
    • オンラインデザイン制作サービス機能
  • raksul.com で共通に使える汎用レイヤー
    • ラクスル会員の認証、認可機能
    • ECの基本機能

と分析しています。

ハコベル事業でも物流の輸配送管理システムなどは、物流全般で共通に使える汎用機能レイヤーと言えるかもしれません。

裏を返すとこれらの機能の汎用化ができていないために、既存事業とシナジーのある多角的な取り組みの開発スピードが落ちていたり、顧客体験の低下や、事業の機会損失が出始めているようにも見えます。

今回のプロジェクトでは、これらの機能を各レイヤーにおいて、社内外の他サービスと接続しやすく切り出して作り直し、そしてそのアーキテクチャーを継続していけるような開発体制を作っていくことが重要となります。

raksul.comの印刷サービスや集客支援サービスは、これらの汎用機能の上に成り立つ一つのサービスという位置づけになります。後付にはなりますが、これがRaksul Platform Projectと呼ばれている所以です。

 

アンチパターン2: データベースとアプリケーションの切り方を間違える

よくあるアンチパターンな構成としては、モノリシックなデータベースが中心にあり、ユーザー向け、管理画面やAPIなどの多数のWebアプリが読み書きしている状態です。

立ち上げ期はスモールな構成なのでいいのですが、そのまま多角的に機能追加を行ってしまった結果、データベースとメインのWebアプリ、管理画面などが肥大化していき、辛くなって対処療法的に小さなアプリだけを切り出し始めます。

 

こうなってしまうと、

  • 各アプリケーションで似て非なるモデルが冗長に開発され、コピペしはじめる(DRYでない)
  • 各アプリケーションがそれぞれの事由でスキーマを変更、書き込みをしていき、影響範囲が広くなる
  • 新しいエンジニアやオペレーターがシステムをキャッチアップするのに時間がかかる

といった弊害が出てきます。

開発の現場から悲鳴が上がり始め、内部にインターナルAPIを置き、データベースやビジネス・ルールを一定ラップして凌ぐことになります。ラクスルにも内部にAuth API, Order APIといった比較的新しくて小さな内部APIが存在していて、一時的な対処はしている状態ですが、抜本的な解決には至っていません。

本質的には適切な関心事であるドメイン毎に、データベースを分割して、各ドメインのアプリケーションが、

  • エンドユーザー向けWeb画面
  • 管理者向けWeb画面
  • 他アプリケーション向けAPI

の3つのプレゼンテーション機能を持ち、一つのデータベースと一つのストレージ(AWS S3 のバケット等)の保全に責任を持つ、という構成にすることで、機能の凝集度を高めるべきです。

早期にこういった発想でデータベースとアプリケーションの切り出しを意思決定したかったと後悔することがよくあります。

 

アンチパターン3: マイクロサービス化しすぎて逆に効率が落ちる

上記で説明した、データベースとアプリケーションの切り方についてですが、柔軟性を求めすぎて細かく切りすぎてしまい、ピタゴラスイッチ状態になるとまた問題が出てきます。

  • dockerなどを使っても環境セットアップするのが辛くなる
  • データを非正規化しすぎて不整合が起きやすくなる
  • 障害対応やチューニングの難易度が上がる

ラクスル内部でも、Auth APIがつらい、直接usersテーブル参照したい、joinしたいといった声が聞こえることがありますが、まさにといった弊害かと思います。それは近くにあるべきはずのものが遠くに切り出されてしまっている可能性があります。

一定仕方のない部分はありますが、なんでもかんでもAPIにして分割していくということではなく、逆に統合すべきドメインを見定め、的確にケーキカットしていくことが非常に重要だと思っています。

ラクスルの場合は、

  • 全社共通で使われるであろう機能レイヤーに2アプリケーション
  • ラクスルのコア技術で印刷事業共通に使われるであろう機能レイヤーに3アプリケーション
  • raksul.comのECサイトのレイヤーに2〜3アプリケーション

の合計7〜8アプリケーション構成程度になってくると思っています。
これでも少し多いですが、これ以上切り出すのは多すぎると思っています。

 

アンチパターン4: テストしにくい状態で身動きが取れなくなる

フレームワークや言語のバージョンアップをするというプロジェクトを今まで何度も経験していますが、ここで辛いのが、テストがないアプリケーションのマイグレーションです。

例えば、Rails5が出ている時期に、 テストが不十分なRails3の巨大なモノリシックなアプリがあってなかなかマイグレーションできませんでした。「Rails3 なんですねえ。。。」と採用面接で何度言われたことでしょう。

持続可能な事業を支えるアプリケーション、開発組織であればここは妥協すべきではありません。

ラクスルでも、PHP + テストがないアプリケーションなどが一部あります。かつ、それがとても事業上重要なアプリケーションだったりします。日々の開発では、End2Endテストと人力のQAで品質を担保していますが、もう少し細かいレベルでのテスティングに力を入れなければ長くアプリケーションの品質を保つのは難しいのは言うまでもありません。

思い切ってこれらのアプリケーションをRuby on Railsでテストフレームワークも含めて標準化し、テストを書きながら作り直していく必要があると考えています。

 

まとめ

さて、ご紹介してきたアンチパターンを踏まえた上で、今のところのRaksul Platform Projectの基本的な方針は以下のような形です。

  • レイヤーとドメインを定義し、コア機能を汎用的に切り出して社内外と接続可能な状態にする
  • 1アプリケーションに対して、1データベース、1ストレージ構成のアプリにする
  • アプリケーションを細かく切りすぎないように7〜8アプリケーションぐらいに再分割して切り出していく
  • Ruby on Railsでアプリケーションを標準化してreadable、testableな状態にする

ラクスルの開発現場はこれから大きく変わろうとしています。また、これによりシステム構成と事業・組織構成の間の歪を最小化することができる考えています。

印刷業界をリードできるコア機能の開発が段々できるようになってきた今、今度はそれらをモダンなアーキテクチャーに載せ替えていき、ワクワクするような経営・事業戦略と共にエンジニアもさらに高いレベルに成長できると思います。

ラクスルでは、絶賛エンジニア募集中です。
「仕組みを変えれば世界はもっとよくなる」
世界が変わっていく瞬間を一緒に体験したいエンジニアの方、お待ちしています♡

スピードチェック入稿リリース秘話

ラクスルの数少ない女子エンジニアの加藤です。

今回は、8月末にリリースしたスピードチェック入稿のリリースまでのプロセスを書いてみたいと思います。

スピードチェック入稿とは

そもそも、チラシや名刺などの印刷をインターネットで注文したことのない方もいらっしゃるかもしれません。

ラクスルは、印刷物を扱うECサイトです。通常のECサイトと違って、商品を選んで配送先と決済方法を選んでもらうだけでは注文は完結しません。お客様が印刷するデータを入稿するという印刷ならではのステップがあります。

また、印刷用データはラクスルで印刷に適しているかどうかチェックして、適していない場合、お客様は再度入稿する必要があります。

これまで、ラクスルではデータが印刷に適しているかどうか、オペレーターが一つ一つチェックし、場合によっては微修正をしていました。人手でやっているため、印刷データが確定して実際に印刷工程に進む準備ができるまでに1日以上かかってしまうこともあり、急いで印刷物が欲しいというお客様の要望になかなか答えられていませんでした。

そこで、サイトを訪問している最中にその場でチェック結果がわかるようなシステムを開発しようということになりました。それが「スピードチェック入稿」です。

スピードチェック入稿画面

スピードチェック入稿画面

プロジェクトの始まり

入社してしばらく経ちそろそろ会社に慣れてきたかと思っていた4月末、プロジェクトのミーティングに呼ばれました。データチェックを自動化する理由が共有されて、成功させるぞという強い意志が感じられましたが、参加メンバーのドメイン知識が十分ではない状況で、議論も少し混乱気味。私個人としては不安がありつつも、とにかくやってみようという気持ちでミーティングを終えました。

プロジェクトは、ラクスルで提供しているデータチェック業務理解から始まりました。実際に、オペレーターの方が作業している所をメンバーみんなで見させてもらう時間もとりました。

・どんなデータが入稿されるのか
・どんなデータのどんな点を確認しているのか
・どんな修正を行っているのか
・どんなメールをお客様に送っているのか

最初はこのような基本的なポイントを一つ一つ確認していき、データチェックのドメイン知識の理解を深めていきました。

デザインと設計のプロセス

スピードチェック入稿のデザインチームはデザインスプリントを実施。毎スプリントごとにお客様からのフィードバックを受けてデザインが進みました。

使う人はどんな印象を受けるのか、どんなところで操作に詰まったり、戸惑ったりするのか。私自身はデザインチームではありませんでしたが、週ごとのデザインとフィードバックのシェアや、お客様へのインタビューの同行を通じで、ユーザ理解を深めることもできました。

ビジネスチームによるデータチェック要件の詳細化とデザインと同時並行で、システムの設計も始めました。

システムは、すぐにWebで時間のかかる処理を実装するときのオーソドックスな構成に決定。
・フロント:データチェック用のAPIを呼び出し結果を描画
・データチェック用のAPI: フロントから受け取ったリクエストを受けてジョブをキューイング
・バックエンドジョブ:データチェックやPDF変換を実施

システム構成

システム構成(模式図)

デザインスプリントが進んでいる間に、最小単位で連携して動くものを実装していきました。

初めて一緒に仕事をするメンバーで構成されたチームでしたが、REST APIなど共通した設計スタイルがあると設計検討も早く進むのを改めて感じました。

自走チームの開発スタイル

メンバーが各作業を進める中、試行錯誤したのはコミュニケーションとタスク管理でした。

ビジネスメンバー、デザイナー、エンジニアそれぞれに違うバックグラウンドを持ち、比較的自由に仕事をするメンバーが揃ったため、仕事自体はすごく速く進むのですが、みんなが協力しないと一つ一つの機能が動きません。

どんな風にコミュニケーションするか、どんな風にタスクの状況を共有したり管理したりするか。朝会や毎週の振り返りで、率直に意見やアイデアを言い合って、改善して進めました。

振り返り

毎週末の振り返り

以前のブログ記事では、開発スプリントやペアプロの紹介もありましたが、今回はペアプロは実施せず、また開発スプリントは回しつつも運用は比較的ゆるめ。それぞれのメンバーのやりやすさを優先させつつ、アクションが滞らないようにコミュニケーションをとって乗り切りました。

やっぱり何か起こる結合とテスト

いくつかのコンポーネントが連携するシステムの開発では、結合とテストの段階になって様々な考慮漏れが判明してスケジュールが遅れるというのが開発でよくある光景ではないでしょうか。

今回のプロジェクトでは、かなり前段階で様々なケースのテストデータを準備したりエラーケースの検討をしてきましたし、結合して動かすこともその都度行なっていましたが、それでもやはり本格的な結合やテストの段階で色々な問題が起こりました。

例えば、初めは入稿している原稿の縦横の方向を自動判別しようとしていましたが、チラシでは判定できるけれども、名刺では判定できないケースがあるということが間際になってわかったりしました。

もちろん前倒して考慮できればベストだと思いますが、初めての要素があるプロジェクトではなかなかそうもいかないものです。このプロジェクトでは見つかった時にその都度、チームで学習しながら、一つ一つアクションを決めていきました。

リリース!

風邪でチームメンバーが次々と休んでスケジュールが遅れ気味になったり、間際で解決が危ぶまれる課題が発生したりと、様々なことがありましたが、8月末に当初の予定通りリリース。日程的にタイトな状況になっていても、みんなでランチに行ったりとチームの雰囲気を保ち、コミュニケーションを密に取れるようにしていたのも、逆に予定通りのリリースに不可欠だったかもしれません。

リリース後も、スピードチェック入稿の状況をチームでモニタリングしながらの対応や改善、対象商品の追加が続き、多くのお客様に使われるサービスに育ってきました。フェーズが移り変わるとチームの状況ややることも変わっていきますが、これからもビジネスメンバー・デザイナー・エンジニアの垣根を超えて、お客様の体験がよくなっていくような開発を続けていきたいと思います。

 

ラクスルでは、絶賛エンジニア募集中です。
「仕組みを変えれば世界はもっとよくなる」
世界が変わっていく瞬間を一緒に体験したいエンジニアの方、お待ちしています♡

Electronを使ってデスクトップアプリを開発しました

ハコベルの開発をしている吉岡です。

入社してからずっと印刷ECの開発をしていましたが、
今年の5月からハコベルチームに移って開発してます。

ハコベルはインターネットを使って簡単に荷物の配送を手配できる
運送のマッチングサービスです。
もっと詳しく知りたい人はこの辺とかをぜひ見てみてください。

ちなみに、先日「Ruby biz Grand prix 2016」でハコベルがグランプリを受賞しました。
興味のある方は是非こちらもご覧ください。
https://www.wantedly.com/companies/raksul/post_articles/46184

それでは開発の話へ。

続きを読む

ラクスルECサイトとInternet Explorerの関係

はじめに

ラクスルのフロントエンド周りを担当している野口です。

デザイナーとフロントエンドエンジニアが社内に0(正確には前にいたがしばらくいない期間があった)の状態から、ラクスルにジョインして早2年が経ちました。今ではデザイナー3名、フロントエンドエンジニア3名、サーバーサイドのエンジニアも約3倍近くになり、メンバーがほんと増えたなぁとしみじみ。

さて、今年の1月12日(米国時間)にIEのサポートポリシーが変更となりました。使用しているOSでサポートされる最新バージョンのIEだけが、技術サポートとセキュリティアップデートを受けられるということに。
※ Internet Explorer サポートポリシー変更の重要なお知らせ
https://www.microsoft.com/ja-jp/windows/lifecycle/iesupport/

変更から8ヶ月以上が経過しましたが、みなさんが作っているサイトを利用しているユーザーの環境に変化はありましたか?開発する上でも変化はあったでしょうか?

IEのサポートポリシー変更にともない、確実に変化があったはずです!弊社ラクスルが運営するネット印刷のECサイト(raksul.com)においても変化があり、「ラクスルECサイトとInternet Explorerの関係」と題して、変化や取り組んだことについて書いてみたいと思います。

続きを読む