2019.06.27

321

Go+Rails+SQS+S3で社内のオペレーターチェック入稿システムを刷新した話

こんにちは。サーバーサイドエンジニアの荒井です。
ラクスルでデータ入稿〜印刷用データ作成に関わる開発チームに所属しています。

以前、GoのおすすめDIツールについての話がありましたが、今回は、Goを使ってラクスルのオペレーターチェック入稿システムを刷新した話について書きたいと思います。

新システム構成図
新システム構成図

オペレーターチェック入稿とは

ラクスルは、印刷物を扱うECサイトです。したがって、お客様に印刷用のデータを入稿していただく必要があります。

ラクスルでは現在、2つのデータ入稿方法をご提供しています。

1つは、システムが全自動で印刷用データを作成するスピードチェック入稿です。
(過去にスピードチェック入稿リリース秘話そうだ スピードチェック入稿のテストを自動化しよう でも紹介しています)

もう1つは、DTPオペレーターがデータを1つ1つチェックして印刷用データを作成するオペレーターチェック入稿です。本来はすべてをスピードチェック入稿でまかなえるのが理想ですが、まだスピードチェック入稿が未対応なデータや商品があったり、お客様がオペレーターチェック入稿を希望される場合もあり、社内では多くのDTPオペレーターが活躍しています。

オペレーターチェック入稿では、DTPオペレーターがInDesignやIllustratorを使って適切にPDFを作成し、社内システムでそれを印刷用データに変換することで、お客様の入稿データから印刷用データを作ります。

オペレーターチェック入稿イメージ
オペレーターチェック入稿イメージ

オペレーターチェック入稿の旧システムと問題点

旧システムは下図のような構成となっていました。

旧システム構成図
旧システム構成図

社内には目黒・京都など複数拠点があり、いずれの拠点でもDTPオペレーターが作業をしています。オペレーターが作業を終えると、InDesign内部に設定したjsxスクリプトが、端末にマウントされた各拠点のNFSへファイルをアップロードします。旧オペレーターチェック入稿システムはAWS上にあり、各拠点のNFSからAWS上のNFSへ入稿データを集約し、印刷用データに変換したのち、各拠点のNFSへアップロードする形となっていました。

これにはおおまかに2つの問題がありました。

  • 旧システムが不安定
  • 重いファイルのやりとりが多く、社内 – AWS間のVPNが詰まる

新システムの構成とポイント

新システムはこのような構成となっています。各ポイントについて詳述します。

新システム構成図
新システム構成図

ファイルストレージをS3化

AWS上のNFSをS3に移行し、インターネットを通じてS3にアップロード・ダウンロードすることで、VPNの混雑を回避できるようになりました。

(1) (2) Goを使ったクライアントアプリ

各オペレーターの端末にクライアントアプリをインストールします。
クライアントアプリはS3へファイルをアップロードして、新システムのAPIにどういった処理をしてほしいかをHTTPリクエストとして送信します。

このクライアントアプリは、旧システムと同様にInDesign内部に設定したjsxスクリプトから実行されるため、DTPオペレーターのオペレーションを変更する必要はありません。

オペレーターの利用しているOSはWindowsとMacがあるため、Goで作って各OS向けにクロスビルドすることでクライアントアプリを作成しています。クライアントアプリのアップデートは頻繁に行いたいので、自動セルフアップデートの機能もつけています。

(3) 新オペレーターチェック入稿システム: Railsを使ったサーバーアプリ

旧システムは外部のソフトウェアだったのですが、問題が起きた際ベンダーの対応待ちになったり、内部処理の改善が難しいという問題がありました。

そこで、スピードデータチェック入稿のシステムをベースに、新オペレータチェック入稿システムを開発しました。新システムにはRailsを使い、APIサーバーと、外部のPDF検査・修正ツールを使ったジョブ管理システムを作りました。これにより、スピードデータチェック入稿システムとオペレータチェック入稿システムで内部処理のノウハウを共有できるようになり、印刷用データの品質改善を展開しやすくなりました。

また、クライアントアプリと定義を共有するためにProtocol Buffersを利用して、一部のコードを自動生成しています。これにより、改修や機能追加がシームレスかつスピーディに行えています。

(4) (5) SQSのメッセージを受け取ってS3からローカルにダウンロードするデーモン

S3からの印刷用データのダウンロードについても、既存のオペレーションに影響がないように作る必要がありました。旧システムと同様に、各拠点のNFSをオペレーターの端末にマウントして、印刷用データはそこに配置します。

このために、S3に印刷用データが置かれたときにイベント通知されるよう設定しています。各拠点のNFSに配置したデーモンが、SQSからReceiveMessageしてS3から印刷用データをダウンロードします。このアプリケーションについてもGoで作成しています。

まとめ

今回は社内でオペレーターチェック入稿がどのように行われているかと、そのシステム刷新について、Goの活用事例を含めて書きました。

過去の記事ではgRPC Client Interceptor入門 with Ruby でgRPC導入についての話がありましたが、どのようなサービスや言語、アーキテクチャにするかは、エンジニアたちが主体的に話し合って決めています。

オペレーターチェック入稿は、先月すべての拠点で新システムに移行完了しました🎉
チームでは引き続き、オペレーターが使いやすいように新システムの改善や、新たなプロジェクトに取り組んでいきます。

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

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

ラクスルでは、印刷・広告・物流の業務について解像度を深めながら、技術を使って課題を解決していきたい方をお待ちしています!是非一度オフィスに遊びにきてください!

 

印刷のラクスル(https://raksul.com/) のサーバーサイドエンジニアです。データ入稿周りから発注用データ作成までを担当していて、主にRailsとGolangを書きます。

2019.06.27 #Products
321

Go+Rails+SQS+S3で社内のオペレーターチェック入稿システムを刷新した話

この記事のURLをコピーする
この記事をシェアする ツイート シェア はてな