hakobera's blog

技術メモ。たまに雑談

Quipper の DevOps のお仕事と技術的課題

このツイートがそれなりに反応があったので、有言実行してみる。

最初に書いておくと、これはQuipperの採用のための記事です。Quipper では下記のようなお仕事、技術的課題の解決に興味がある DevOps エンジニアを絶賛大募集しております。興味のある方は、Wantedlyの募集ページ から「話を聞きに行きたい」をクリックしてみてください。応募までは行かないけど、もっと詳しい聞いてみたいという方は私個人にでも良いのでご連絡ください。（Twitter で @hakobera にメンション or DM、または hakoberaアットgmail.com までメールください）

2015年6月時点での技術的課題一覧

  • Heroku から AWS への移行
  • Elastic Beanstalk で運用しているアプリの Docker 化
  • Infra As Code のより一層の推進
  • BigQuery を利用したレポート基盤の構築
  • OSS 業務

合わせて使いそうな技術一覧

  • AWS 全般
  • Docker
  • BigQuery
  • Nginx
  • Hashicorp 製品全般（主に Terraform と Atlas)
  • Ruby/Python/Go など（なんらかの言語でのプログラミングスキルは必要）

Heroku から AWS への移行

Quipper は開発環境も合わせると、200以上のアプリを Heroku で稼働させている Heroku のヘビーユーザです。特に Heroku Review Apps と同じような仕組みをかなり昔から運用していて、便利に使っています。詳細は以下のCTO のブログを参照。

非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog CircleCIでfeature branchをHerokuに継続deploy - Masatomo Nakano Blog

すごく便利に使っている Heroku ですが、以下の理由から一部のアプリケーションについては AWS への移行を検討しています。

  • アクセスが増えてきて、2X Dyno でさばけなくなってきた。現状 PX (Performance) Dyno を利用しているが、$500/Dyno/Month と高く、コストパフォーマンスが結構悪い。
  • サービスの主戦場が現時点ではアジア（フィリピン、インドネシア、タイ）であり、US リージョンしかない Heroku だとネットワーク的に遠く、レスポンスが気になる
  • セキュリティが緩くなりがちである（詳細は書けないが、IPアドレスが固定できないので、制限が色々とかけにくい。固定IPをつける addon もあるが高い）

AWS に移行するにしても、現状の feature branch を簡単にプレビューできる環境は維持したいので、Docker を利用して以下の構成にする予定です。

なお、SPDY/HTTP2 を利用したいので、Elastic Beanstalk の前段に Nginx を置く予定（現状も、Heroku の前段に Nginx を置いている）

Elastic Beanstalk で運用しているアプリの Docker 化

Heroku の AWS 移行とも絡むのですが、現在 Elastic Beanstalk で運用している Worker アプリケーションを Docker 化するというのも課題の1つです。Elastic Beanstalk は大変便利ですが、2点ほど大きな問題を抱えています。

後者は気合で乗りきれなくもないですが、前者は開発が相当やりにくくなっていたし、Quipper の他のサーバは Ubuntu なので、ここだけ OS が異なるのは管理上も面倒である。ということで、ここも Ubuntu で管理できるように Docker 化をしたいと考えている。

Infra As Code のより一層の推進

現在の Quipper の Infra As Code のレベルは、

今後もこの方向性は強く推進していきたい、アイデアとしては色々とあるし、ツールも進化していくの継続的に改善していきたい。

  • ServerSpec によるインフラテストの追加
  • CircleCI 経由で master ブランチの Ansible の適用の自動化
  • Terraform の適用範囲の拡大
    • CloudFormation テンプレートを Terraform で書き換え
  • Docker イメージの自動ビルド

など。この分野はやることが無限にある感じなので、自動化大好きな方をお待ちしております。

BigQuery を利用したレポート基盤の構築

docs.google.com

上記スライドの後半の事例で書いているように、データの投入は fluentd/embulk/mongobq などで解消済みであるが、スケージューリング、エラー時の再実行などの処理基盤がまだまだ弱い。現状、レポートの数がそれ程多くないので何とかなっているが、今後の業務拡大により回らなくなる可能性が高く、ココは早急に改善が必要だと考えている。

以前発表した BigQuery GAS 連携は1つの解にはなっているが、単純なレポートには良いが、中間テーブルを作成しながら集計していくような複雑なジョブの実行には向かない。これらに対する現在考えている解決策は以下だ。

  • Job ネットの構築
    • Luigi が良さそう
    • Luigi の BigQuery Integration である Luigi-BigQuery を書いて、一部のレポートに適用済みで良い感じ
  • スケジューラの改善
    • 現状の Jenkins から、スケジューリングに特化したミドルウェアへの移行
    • Rundeck が乗り換え候補。スケジュールの良し悪しはまだ良くわかっていないので、スケジューラの選定、運用経験がある人に話を聞きたいところ。
  • 可視化 (Visualize)
    • コストさえ許せば選択肢は色々とある。データサイエンティストの人と相談して決めていきたい。
    • BigQuery コネクタのある製品：Mode Analytics, Bime, Chario, [Tableau(http://www.tableau.com/), QLikView など
    • GAS で何とかするか、ゼロスクラッチで作るのも場合によってはあり

レポートの処理速度に関しては BigQuery が全てを解決してくれたので、スケジューラの構築、安定運用と可視化に取り組んでいきたい。

OSS 業務

これは課題ではないのですが、必要に応じて、OSS にコントリビュートする、OSS を書くというのも Quipper の DevOps の重要な仕事の1つなのであげておきます。書いたものを OSS として公開するのは、業務に支障がない限り、特に制限はありません。

現在使っているものも、使っていないものも含まれていますが、以下にこれまで Quipper の業務に関連する OSS をあげておきます。

業務のためにコントリビュートした OSS

業務のために書いた OSS

同僚のエンジニアが書いた最近の Quipper の状況を知ることができるブログ記事