読者です 読者をやめる 読者になる 読者になる

try! Swift Tokyo 2017に行ってきた

f:id:y_koh:20170302095411j:plain

iOSエンジニアの高です。去年に引き続き今年もtry! Swiftに参加してきました。

www.tryswift.co

最近のカンファレンスは後日スライドだけでなく動画まで公開していたりします。try! Swiftの場合はスポンサーのRealmが公開してくれてます。 try! Swift Conference

こうやって資料が共有されると、そもそも参加する必要はあるのだろうか?と思ってしまいがちなのですが、やっぱりそこでの空気感だったり、他のエンジニアとの交流だったりは結構大事だなと思っていて出来る限り参加するようにしています。

海外からはもちろんですが、国内でも東京以外から参加されてる方も多かったです。僕が話した感じでは福岡が多かったなという印象です。

会場

f:id:y_koh:20170304145228j:plain ベルサール新宿セントラルパークビルで行われました。天井も高く、広々とした会場で良かったです。

所感

今年も興味深い話ばかりでしたが、去年に比べるとSwift言語自体に突っ込んだ話は少なくなったかなという印象でした。去年はプロトコル指向、型消去、LLDB、オープンソースSwiftなどもう少しコアな話が多かったと思います。

この一年で一通り出尽くしたからか、もしかしたら1年経ったけれど悩みのタネは特に変わってなくてずっと同じ話になってしまうのも、、ってことなのかもしれませんね。

気になったセッション

気になったセッションをいくつかご紹介します。

Swift開発者が知りたかったけど聞きにくい機械学習のすべて

機械学習は最近至る所で耳にするので一度取り組んでみようと思ってるところです。このセッションでは機械学習はiOSアプリ開発と類似点が多いのでiOSエンジニアであれば機械学習を始めやすいのではという話をしていました。

UIをSwiftyに書く

やっぱり海外の方はStoryboardが嫌いみたいです😅 たしかにイケてないところはたくさんある。もう少し自然な形で統合してくれと誰もが思ってるでしょう。後述しますが、色の扱いもどうにかしてほしいところです。。

それでもUIをコードで書くと後から見たときに脳内変換が必要になってつらいので、僕は使えるところではStoryboard・xibを使うようにしてます。

独自のツールを構築する

ざっくり言うと、みんなが作ってるアプリはXcodeで作るのに適してないからReactNativeで作ろうぜって話でした。そうきたか!という感じでしたが、納得できるところは多かったです。

Appleのアプリを見ればわかると思いますが、ほとんどがスタンドアロンアプリです。もちろん通信もしますけど、それがメインではない。Xcodeはそういったアプリを作るための環境として提供されているので、API指向なアプリを開発しやすい環境ではないとのことです。

その点ReactNativeはAPI指向なアプリと親和性が高いとのことです。ReactNativeはクロスプラットフォームの文脈で語られることが多いですが、単純にAPI指向なアプリを作りやすいそうです。

ReactNativeは出た当時一瞬だけ触ってみましたが、アプリを起動し直さなくても変更点が反映されるHot Reloadingが本当に羨ましいです。

テスト可能なコードを書くということの2つの側面

テストする際に問題になるのが環境です。自動テストするには毎回同じ環境を用意する必要があるのですが、特定の環境を作り出す方法として、環境をグローバルなstructにまとめてしまい、必ずここを通るようにするという方法を紹介してました。

struct Environment {
  let ApiService: ServiceProtocol
  let cookieStorage: HTTPCookieStorageProtocol
  let customUser: User?
  let dateType: DateProtocol.Type
  let language: Language
  ...
}

Kickstarterアプリではこのリストが25個程度続くそうです。

これが本当にbetter wayかはやってみないとわからないですが、アプローチとしては面白いなと思いました。

Swiftで堅牢なカラーシステムを構築する

アプリで使っている色をプログラマティックに変更できるようにする方法を紹介しています。ZEPLINとの共有や、IB上で使用するためのパレット作成などの話もありました。

しかし、IB上で色を指定してもXMLを開いてみるとわかると思いますが、名前がついていないため参照することが出来ません。つまりプログラマティックに色を変えることが出来ません。これに関しては今のところ色は必ずコードで指定するという縛りを導入するしかなさそうです。

SwiftであればIBOutletプロパティdidSetで指定するのが良さそうです。

後半、色覚異常についての話もありました。僕もこの辺は気にはしているのですが、トレタアプリが複数人で使用するアプリのため特別な対応は難しいかなぁと思っているところです。

チームの生産性を改善するために決断疲れを最小化する

仕組み化やルール化できるところはなるべくそうして決断にかける時間を最小限するという話です。Pivotal Labでの一日の過ごし方をベースに何をやっているかを説明されていてとても良くまとまっていました。

  • 朝食
  • 朝礼
  • プロジェクト向けの朝礼
    • ファイル置き場の話。Xcodeのグルーピング
  • ペアプログラミング
  • MARKアノテーション
    • 人によって書き方が変わらないように、ViewControllerのテンプレートをXcodeのスニペットとして使っている
  • 休憩に卓球
  • ふりかえり(毎週金曜日)
    • Keep😀、Discuss😕、Improve😭

最近トレタでも属人化排除のために何が出来るかという話を良くしているところだったので色々と参考になる話が多かったです。ルール化することで窮屈になってしまっては本末転倒ですが、余計な決断を減らすためにルール化するというのは取り入れたいところです。

懇親会

f:id:y_koh:20170304145241j:plain 懇親会は会場から2駅離れたキリストンカフェで行われました。写真を見てもらえるとわかると思いますが、すごい人数です。これだけのiOSエンジニアが集まる機会はそうそう無いですよね。

とても楽しく有意義な時間でした。

おわりに

去年に引き続き今年も楽しませてもらいました。運営も全体的にとてもスムーズで素晴らしかったです。来年もあればまた参加したいと思います。

CTOがチームマネージメントじゃない方向に向かう時に何をするべきなのか - トレタにおけるmasuidriveの役割 2017年版

トレタ CTOの増井です。

トレタは創業して3年半、エンジニアも2名から13名に増え、私の役割も変わってきました。

当初は一人目のエンジニアとしてアプリの設計やサーバサイドのコードを書いたり運用全般を行っていました。

人数も増え、2年を過ぎたあたりからエンジニアリングの中で私が率先してやる必要のあることがほぼなくなってきました。むしろ海外展開で出張が増え、連続した時間がとれずに進捗を遅らせる原因になってしまうこともありました。

最近の論調では、メンバーが増えるとCTOはマネージメントや組織作りに移行して行くみたいですが、私はそっちに興味が全然なく、向いているとも思えませんでした。そもそも私は上司を持ったこともないし、決められた環境の中で働くのがとても苦手なので。

私が「組織を作って管理して行く」のは無理というのはトレタ設立当初から分かっていたことなので、メンバーを増やす時は「自分で目標を作って管理していける人」を基準に採用していました。そのため、多くの人がプレイングマネージャとして動け、開発部にはマネージャ職がないまま3年間進んできました。 しかし、人数が増えると人を管理するためでなく、他部署への窓口となる人や、担当のいない仕事を拾いタスクにしてメンバーに割り振る人が、必要になってきました。そこで「エンジニアリングマネージャ」として、昨年4月に入社した酒井がプレイングマネージャとして、その辺の面倒を観てくれるようになりました。

さて、そうなると、私が関わらなくても開発は順調に行われていきます。特にトレタ本体では開発フローが出来上がっており、連続した時間を取りにくくなった私が下手に関わると開発サイクルの歪めてしまうことになります。

2017年は「組織と異なる視点からの問題解決」を行動指針に

そんな感じで、シンガポール立ち上げも落ち着いた2016年半ばから「自分はCTOとして何をして会社に貢献するべきか」という事をずっと考えてきました。

CTOとしていろんなイベントに呼ばれる時には他社のCTOに話を聞いたり、IVS CTOのアンカンファレンスでは「マネージメントしないCTO 〜 We are NOT Naoya.」という枠をもらって色々なCTOと話し合ったりしました。

先行事例として、海外のCTOはどうなのかな?と聞いたら、AWS CTOのWernerさんのブログを教えてもらいました。 10年前ですが「The Different CTO Roles」 という記事の中では「CTOとは何をする人なのか」という話から、その役割として4種類に分類されていました。

  • Infrastructure Manager
  • Technology Visionary and Operations Manager
  • External Facing Technologist
  • Big Thinker

前の二つはエンジニア組織を直接管理する方向で、後の二つは会社を新しい方向に導くために他の部署とも連携取りながら影響して行くという風に説明してます。目線がエンジニア組織に向くか、会社(スタートアップの場合は ≒ CEO)に向くかの違いでしょう。

このブログを読むうちに、イベントでよく聞くCTOの役割は前者であり、私が目指すのは後者じゃないかと感じてきました。 特に創業CTOとして、前職なども含め6年間もCEOの中村と一緒に仕事をして来て、私に求められているのも後者としての役割だと感じていました。

「Technology Visionary」は「CTOは技術を引っ張らなければ行けない」という気持ちがありCTOは当然あるべき役割だと思っていましが、この分類では私の目指す方向に入ってこないことは、割と衝撃的でした。

この記事や関連記事を読み、「エンジニアの先頭に立ち、引っ張って行くより、一人突っ走って『こういう道があるんだ』という事を観てもらえる立場」になりたいなと明確に思えるようになったのは11月頃でした。

また、事業や会社の進むべき方向をもっとも理解しているべき創業者の一人として、事業や会社の課題をチームとは違う角度で解決を模索するという事も「やっていいんだ」と思えるようになってきました。 これをやると開発チームとは距離ができてしまう可能性もあり、「開発部 CTO」として正しい道なのかずっと気になっていました。

そこから自分の役割をまとめて2017年のJob descriptionを下記のように書いてみました。

開発部の一部としてのCTOと、事業を包括的に見る共同創業者の立場で分けて考えてみました。

「組織と別の視点から問題を解決する」というのが2017年の行動の大枠になります。

# 開発部 CTO職

技術とビジネス、両軸のバランスを保ちながらトレタを伸ばす役割。

## 事業の技術判断
- 事業が生まれるところに技術視点を持ち込む
- 各プロジェクトの利用技術・アーキテクチャと問題の把握
- 各プロジェクトの目的や事業意義を把握し、メンバーのサポートを行う

## 技術広報
- トレタの中で起こってる技術を外に伝えて、技術力をトレタのブランド力向上に繋げる
- 各プロジェクトの利用技術・アーキテクチャと利点・欠点・の把握
- トレタの開発文化を明文化して内外に発信、定着させて行く

## 採用
- 会社説明と面接
- 採用広報

## メンタリング
- 必要に応じて1 on 1などを行う

## アーキテクト
- 基本設計の部分でデータ構造や全体の構成などのレビューを行う

## 隙間
- ハードなど、誰も持たない技術に関する案件


# 共同創業者職

トレタの創業者として、既存の関係性やビジネスに囚われずにトレタを伸ばす役割。

## 組織横断の問題解決
- 営業やマーケなど開発部以外でもエンジニアや共同創業者の視点からできる問題解決を提起する
- 特に海外展開を考慮した問題解決を行う

## TORETA LAB
- 非連続にトレタを成長させる種を見つける
- 技術を主とした新規事業開発
- プロダクト本流外を技術で解決するプロダクト
- どっかで学生バイトかインターン入れたいなぁ

去年の秋ぐらいから、上に書いたようなことを意識しながら仕事をしてきました。

もうトレタ本体の開発で日常的に私が関わる部分はなくなりました。新しい機能開発や技術剪定もほぼ全てを開発組織で行なっています。私がいなくてもトレタの開発に困ることはほとんどないでしょう。だからこそ、開発チームから少し離れた、別の視点を持ち込むことで、プロダクトが非連続に成長させていきたいと考えています。

また、チームの人数も増え、層も厚くなったことで開発チームの中からも新しい方向性が出てくるようになりました。

トレタでは3年以上運用して蓄積したお客様のデータを元に、お客様の利益になるデータをまとめて提供して行くためにデータ解析を本格的に始めたところなのですが、数学的な分野は私の苦手なところであり全然手の出てない部分でした。 そこは、エンジニアの芹沢と中村(若い方)を中心に企画・開発してガシガシと出来上がって行く様子を見て、新しく面白いものが出来上がって行くのをワクワクして見ています。

トレタの新しい可能性を見つけるための「TORETA LAB.」を開設

f:id:masuidrive:20170227144754p:plain:w150:right私は今年、アプリ内に面白い機能を入れるSDKを作ったり、新しいハードを作っていたり、営業部の業務フロー改善のお手伝いなど、本体の開発以外だけど「技術で解決」できる問題を探し回っています。会社としてのトレタの引き出しを増やして深みのある会社にしたいのです。その引き出しを作るための「TORETA LAB.」という一人組織的なものを作りました。

「創業CTO」というのは何をやっていても、後から入ったメンバーとしては口の出しにくいものでしょう。しかし文句も言いにくいため、その人の能力が組織の能力の上限になってしまう事も十分に考えられます。しかし、その「口の出しにくさ」をいい方向に生かして、新しいトレタの可能性を作って行く2017年を目指しています。

そして、こんな組織で一緒に働いてくれるエンジニアを募集しています。トレタの技術や組織に共感を持ってくれて「自分はこんな役割で働きたい」と思ってくれる、「こんな役割があるんじゃないか」と考えてくれる人が一緒に働いてくれると非常に嬉しいです。

また、TORETA LAB.では学生のインターン生も採って見たいなーと思っています。何も決まっていないのですがエンジニアリングの好きな学生さんがいましたら、 masuidrive@toreta.in まで気軽にメールいただけると嬉しいです。

Pull Request発行時にそのコミットIDでデプロイされた環境を自動構築してレビュー時/マージ前に確認しやすくする仕組み

インフラをアレしてる佐野です。Pull Request(以下、p-r)が発行されると、そのp-rのコミットIDでデプロイされた環境を自動構築する仕組みを作ったので、今日はそれについて。マージ直前の環境が立ち上がるのでレビューアはレビュー時にコードを追うだけでなく、ブラウザ/アプリの接続先をこの環境に向きかえることで実際のアプリケーションの動作も確認できるようになります。レビューが非常に捗ります。

  1. 動作
  2. 仕組み
  3. GitHubのWebhookについて
  4. 自動構築の処理
  5. Dockerの活用
  6. tmpfsの活用
  7. まとめ

1. 動作

こんな感じです。ここで、この通知するボットおよびこの仕組みを以下、シャイニング・ウィザードと呼ぶことにします。シャイニング・ウィザードというのは好きなプロレスの技でして最初はこの基盤の仮名だったのですが、チーム内で定着してしまったのでもうこれでいいや的な…。ちなみに、Amazon prime ビデオに有田と週刊プロレスとという、くりぃむしちゅーの有田さんがプロレスについてひたすら語るだけの番組があります。これが最高に面白いので、プロレス好きな人にはおすすめです。Amazon primeに契約していれば無料で見れます。

さて、まずは動作の様子です。p-rが発行されるとシャイニング・ウィザードがそれを検知してサーバを作り、IP、APIサーバのURL、APPサーバのURL…を発行しています。

f:id:hiroakis:20170224204927p:plain

p-rがクローズ(マージもしくは単にクローズ)されるとそのサーバを殺します。

f:id:hiroakis:20170220170003p:plain

冒頭でも述べた通り、レビュー、特に画面系のレビューが捗ります。データベースも独立した環境として構築するのでこのサーバでデータ操作をしても本番はもちろんステージング環境にも影響はないです。

2. 仕組み

この記事のために図を書き直すのが面倒なので、社内への説明資料をそのまま転用します。なお、この記事はトレタのAPIサーバ/ウェブサーバを対象としており、そのサーバはEC2を土台にnginx, Rails, Sidekiq, Aurora(MySQL)、Redis、memcachedが存在しています。以下、説明するフローはこの構成前提ものとなります。

f:id:hiroakis:20170221162153p:plain

  1. 開発者(図でいうと「おまえら」)がp-r発行します。
  2. シャイニング・ウィザード(武藤敬司選手の画像)がWebhookを受ける。事前にGitHubのリポジトリの設定でwebhookをシャイニング・ウィザードの動作するサーバに飛ばすようにしておく。
  3. シャイニング・ウィザードがEC2を立ち上げる。この際、user-dataにて下記の(4)(5)の処理を行うようにしておく。
  4. user-dataスクリプトでステージングのデータベースからmysqldumpを取得する。
  5. user-dataスクリプトで各種ミドルウェアのdockerコンテナを立ち上げる(と同時に(4)でダンプしたデータも読み込む)。
  6. シャイニング・ウィザードがansibleを実行してサーバの状態を最新にする。さらにp-rに対応するコミットIDでデプロイを行う。
  7. シャイニング・ウィザードが api-[リポジトリ名]-[プルリク番号].xxxx.com , app-[リポジトリ名]-[プルリク番号].xxxx.com などとしてDNSにレコードを登録する。
  8. 構築したサーバのIPやURLをslackに通知する。

p-rがマージ/クローズされた際の挙動は、単に対象のEC2をterminateして、DNSから対象のレコードを削除する動きになります。

3. GitHubのWebhook

これはご存知の方も多いと思われますが、GitHubにはwebhookの仕組みがあり、issueの変更、リポジトリの変更…などの挙動をhttp/httpsでリモートに通知することができます。本記事の仕組みはこのwebhookを利用しています。GitHubのwebhookにおいて本記事で重要な事柄は次のものになります。

  • X-GitHub-Eventヘッダ
  • POSTされてくるHTTPボディの action 要素
  • 同じくHTTPボディの pull_request.head.sha 要素

p-rのwebhookが飛ばしてくれるデータの詳細についてはこちらのドキュメントを参照してください。

X-GitHub-Eventヘッダ

このHTTPヘッダには「何が行われたか」が入っています。issueの登録/更新/削除なのか、リポジトリに紐づくチームの登録/更新/削除なのか…。p-rの場合、 pull_request という文字列が入ってきます。

action要素

actionにはp-r時にどんな操作が行われたかが記載されています。この記事で重要となる操作は下記の通り。

  • opened: 新規p-rが発行されたとき。
  • reopened: p-rの再開。つまり一度閉じたp-rが再びオープンされたとき。
  • synchronize: p-rが発行されたあとにそのブランチにpushが行われたとき。
  • closed: p-rが閉じられたとき。なお、今回の処理では識別は不要ですが、pull_request.merged 要素のtrue/falseで、マージされて閉じられたのかマージされずに閉じられたかの判別も可能です。

pull_request.head.sha

そのp-rのコミットIDが入っています。つまりこのコミットIDでデプロイすることで、p-rの状態が実現できます。

4. 自動構築の処理

Jenkinsでやってもいいかもしれません(Jenkins鯖を設えて、Webhookの宛先をそこにする)が、今回はGoでWebhookを受けてEC2構築〜デプロイまでを行うサーバを書きました。 実際のコードからいくらか簡略化したコードを下述します。 handler(w http.ResponseWriter, req *http.Request) はgoなhttpサーバのhttpリクエストハンドラです。webhookにて通知されるp-rの action に応じて処理内容を分岐させます。opened および reopened ならEC2の新規作成とデプロイ。 synchronize なら既存のp-rへのpushなので、webhookにて通知されたコミットID、つまり pull_request.head.sha を使ってデプロイを行います。 closed ならいわずもがなEC2の削除やDNSの削除などの後始末を行います。

func handler(w http.ResponseWriter, req *http.Request) {

    // タイムアウト。処理内容に応じて適切に。
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Minute)
    defer cancel()

    // WebHookの通知によって、新規作成、更新、削除それぞれの処理を行う。
    // それぞれgoroutineを起動してバックグラウンドで処理を行う。
    errCh := make(chan error)
    switch action {
    case "opened", "reopened":
        go func() {
            // 作業ディレクトリ掘る、EC2作成、DNS登録、Ansible実行、デプロイ
            errCh <- create(ctx) 
        }()
    case "synchronize":
        go func() {
            // 作業ディレクトリに移動してデプロイを行う。
            errCh <- update(ctx) 
        }()
    case "closed":
        go func() {
            // EC2削除、DNS削除、作業ディレクトリ削除を行う。
            errCh <- terminate(ctx)
        }()
    }

    // 結果を待つgoroutine
    go func() {
        select {
        case err := <-errCh:
            if err != nil {
                slack.Post("エラった")
            }
            slack.Post("でけた")
        }
    }()

    // 処理の結果は待たずにGitHubには200 OKを返しておく
    w.WriteHeader(200)
 }

create()の処理は泥臭い感じになります。create()の中でさらにgoroutineを起動してEC2サーバの起動とDNS登録を行いつつ、別のgoroutineが リポジトリ名-番号 ( repository.full_name-pull_request.number ) みたいな作業ディレクトリを掘ってそこにansibleのリポジトリとrailsのリポジトリをcloneする。そして、EC2を起動するgoroutineとgit cloneするgoroutineが正常終了したら、起動したEC2のパブリックIPでansibleのインベントリファイルを生成する。同様にcapistranoのdeploy.rbを、EC2のIPを使って server '{{ .IP }}', user: 'deploy', roles: %w(web app db) を書き換え、 pull_request.head.sha を使って set :branch, '{{ .Sha }}' を書き換える。そしてcap deploy実行。 update()は単にcapistranoのdeploy.rbのを対象のコミットID( pull_request.head.sha )で書き換えたもので置換して、cap deploy実行。 terminate()はEC2のterminateとDNSの更新。

5. Dockerの活用

トレタではMySQL -> Aurora, Memcached -> Elasticache といったように、基本的にはAWSマネージドを使っていますが、EC2上に何かミドルウェアを構築したいときにはDockerも活用しています。かつてはミドルウェアはrpm/debを煮込んでおいてyum/aptする、またはconfigure && make && make installするような世の中でしたが、今はdockerイメージを使うという選択肢もあります。

Docker公式イメージ

ここで使うDockerイメージは公式イメージを使います。自分で1からDockerfileを書いてもいいかもしれませんが、この手のインスタント環境では基本的には公式イメージで十分です。MySQL, Redis, memcached, PostgreSQL…など著名なミドルウェアのものは大抵公式イメージが提供されていて、docker run時にMYSQL_ROOT_PASSWORDなどの環境変数をセットしたり、ディレクトリマウントを行うことで比較的簡単にコンフィグレーション可能です。例えば、MySQLの公式イメージを使うときのTipsについて紹介します。

  • 自分で作ったmy.cnfを使いたい

文字コードの指定、バッファプールなどの設定などなど、MySQLのコンフィグでケアしたいものをどうやって公式イメージに設定するのか?これはコンテナ側の /etc/mysql/conf.d にmy.cnfを置けば良いです。例えばホスト側に /mem/docker/mysql/conf/my.cnf としてmy.cnfを置いた場合、 -v /mem/docker/mysql/conf/:/etc/mysql/conf.d としてdocker runすることで起動時にmy.cnfを読み込んでくれます。

  • DBに初期データを登録したい

単純にdocker runしたあとに mysql -uroot dbname < mysqldump.sql としてもいいかもしれませんが、 *.sql/docker-entrypoint-initdb.d に置いた上でrun する( -v /mem/docker/mysql/dump/:/docker-entrypoint-initdb.d )と、MySQLコンテナ起動時にデータが流し込まれるようになっています。

シャイニング・ウィザードで使うMySQLは次のdocker runで構築できます。aptリポジトリをセットしてapt-get installしてmy.cnfを置き換えて再起動して、mysqldumpを流し込んで…とシェルスクリプトやansibleでやるよりも簡単です。

docker run --name mysqld -p 3306:3306 \
    -e MYSQL_ROOT_PASSWORD=secret \ 
    -e MYSQL_DATABASE=dbdbdbdb \ 
    -e MYSQL_USER=useruseruser \
    -e MYSQL_PASSWORD=passpasspass \
    -v /mem/docker/mysql/data:/var/lib/mysql \
    -v /mem/docker/mysql/conf/:/etc/mysql/conf.d \
    -v /mem/docker/mysql/dump/:/docker-entrypoint-initdb.d \
    -d mysql:5.6

ここで、 /mem というディレクトリ名で始まっているのは、 /mem を 下述するtmpfsとしてマウントして、mysqldump取得/インポート時の高速化を図るためです。そのためコンテナ側のMySQLデータディレクトリである /var/lib/mysql-v /mem/docker/mysql/data:/var/lib/mysql としてtmpfsである /mem 配下と共有するようにします。

6. tmpfsの活用

若者が知らなかったのでまずは簡単に説明します。tmpfsというのは簡単にいうと、メモリ上にファイルシステムを作るような仕組みです。例えば、 /mem を4Gの容量を持つtmpfsなディレクトリとしてマウントするには下記のようにします。通常のマウント同様、fstabに書いてやれば良いです。 mount -t tmpfs xxxx みたいなコマンド一発でも良いです。

mkdir /mem
echo '/dev/shm /mem tmpfs size=4096m 0 0' >> /etc/fstab
mount -a

これで /mem はメモリ上に展開されたファイルシステムとして振る舞います。さて、上記のようなコマンドをuser-dataに仕込み、 /mem 上でmysqldumpの取得/データ書き込みなどWrite IOがキツイ作業をすればその部分はかなり高速化されます。ステージングDBといえどデータ容量が数ギガあり、export/importに多少時間を食うので、ここは高速化したいポイントでした。ただし、当然、メモリ上にデータが置かれるので、OS再起動したらデータは全部消えます。シャイニング・ウィザードが用意するサーバはそもそも一時的なものなのでデータの保全性については揮発的で良いと考えています。

※ この部分を、日次で mysqldump && docker build && docker push などとしてダンプデータ入りのイメージを作ってしまい、user-dataでは単にdocker pullすれば良いだけ、にしてしまえばもっと早くなるんですがねw

tmpfsのような仕組みは、Writeがきつい、かつ、消えても良いデータの置き場、つまり今回のようなケースで役にたったりします。他にも、例えばtar.gzを生成してscpするバッチがあるとしてそのtar.gzを書き出すディレクトリとか、画像キャッシュサーバがあるとしてそのキャッシュの書き込み場所としてとか。

7. まとめ

f:id:hiroakis:20170224203845p:plain

チームメンバーに欲されている基盤を作るのはインフラ冥利に尽きる。

おわり

© Toreta, Inc.

Powered by Hatena Blog