LCL Engineers' Blog

夜行バス比較なび(高速バス比較)・格安移動・バスとりっぷを運営する LCLの開発者ブログ

AWS C4インスタンスからC5インスタンスへ移行しました

Webエンジニアの森脇です。

先日、EC2のC5インスタンスが東京リージョンでも利用可能になりました。早速、LCLで利用しているc4.largeのWebアプリケーションサーバを、c5.largeへ移行しました。

C5インタンスとは

コンピューティング最適化タイプの第5世代です。第4世代のC4と比較して、新しい世代のCPUが搭載され、ネットワーク帯域幅の拡張など性能アップが行われています。

aws.amazon.com

料金については、c4より20%弱安くなっています(東京リージョンでの比較)。

vCPU ECU メモリ(GiB) Linux/UNIX 料金
c5.large 2 8 4 $0.107 /1 時間
c5.xlarge 4 16 8 $0.214 /1 時間
c5.2xlarge 8 31 16 $0.428 /1 時間
c5.4xlarge 16 62 32 $0.856 /1 時間
c5.9xlarge 36 139 72 $1.926 /1 時間
c4.large 2 8 3.75 $0.126 /1 時間
c4.xlarge 4 16 7.5 $0.252 /1 時間
c4.2xlarge 8 31 15 $0.504 /1 時間
c4.4xlarge 16 62 30 $1.008 /1 時間
c4.8xlarge 36 132 60 $2.016 /1 時間

移行時の注意点

C4系からC5系に移行するにあたり、既存インタンスに対して変更が必要な場合があります。

ENAの有効化

C5系インタンスを利用するには、Elastic Network Adapter (ENA)を有効にする必要があります。

docs.aws.amazon.com

古い世代のAMIを利用している場合は、ENAを有効化する必要があります。有効化の際にはEC2インスタンスの停止が必要がありますが、以下の記事を参考にさせていただき簡単にできました。

dev.classmethod.jp

カーネルの最新化

カーネルが古い場合は、C5へインスタンスタイプを変更すると、EC2が起動しませんでした。カーネルを最新へアップデートすることで、起動できるようになりました。

ap-northeast-1cは利用不可

上述したように、2018/04/22現在では、ap-northeast-1cでは利用できません。インスタンス起動時に以下のエラーが発生してしまいます。

f:id:lcl-engineer:20180423141114p:plain

C4インスタンスとの比較

Railsのアプリケーションサーバの数台の中で1台のみを、c4.largeからc5.largeへ移行しました。

マカレルでc4.largeとc5.largeのインスタンスのloadavgを比較したところ、2割ほどc5.largeのほうが平均して低くなるという結果になりました。 loadavg等の改善が見込めるかは、インスタンス上で可動させるアプリケーションの種類にもよると思いますが、サーバとしてのベース性能は上がっていると判断できます。

f:id:lcl-engineer:20180423141138p:plain

まとめ

C5インタンスは、C4インスタンスと比較して性能は向上しており、料金は下がっています。 リザーブドインスタンスの縛りがなければ、積極的に変更したほうがよいと考えております。LCLもap-northeast-1cで利用可能になった際は、随時切り替えていきたいと思います。

自動タイムトラッキングツールのGTMを手動のTogglの結果と比較してみた

フロントエンドエンジニアの岡田です。 エンジニアは工数を出す機会が多いと思いますが、みなさんはどのようなツールを使っていますか?

私は数年前から、Togglというツールを使って計測しています。 仕事を始める前にはボタンをポチッと押し、終わったらポチッと止める。 Togglの前に使っていたツールを合わせると5年以上このスタイルで仕事をしているため、今ではすっかり習慣になっています。

ただ、手動での計測は、以下のデメリットがあります。

  • 押し忘れたり、止め忘れることもたまにある
  • 突然話しかけられた時など、切り替えるのが面倒

そこで自動で計測ができる、GTMというツールを導入し、使い慣れたTogglと結果を比較してみました。

Togglとは

作業の前後にボタンを押して計測する、手動のタイムトラッキングツールです。 toggl.com

ブラウザでログインをしてすぐに使えます。その他、デスクトップアプリ(Mac, Windows, Linux)やiOSアプリもあります。 デスクトップアプリでは、ポモドーロにも対応しています。 f:id:lcl-engineer:20180416133521p:plain

GTM(Git Time Metric)とは

Gitの履歴と、エディタに入れたプラグインを使って、自動でタイムトラッキングするツールです。 準備さえしてしまえば、あとはいつもどおりコーディングするだけで、自動的に時間を計測してくれます。
Git Time Metric by git-time-metric

GTM導入方法

インストール

Homebrewからインストールします。

brew tap git-time-metric/gtm
brew install gtm

エディタプラグインのインストール

以下のエディタに対応しています。

  • Sublime 3
  • Atom
  • Vim
  • IntelliJ IDEA, PyCharm, WebStorm, AppCode, RubyMine, PhpStorm, AndroidStudio
  • VSCode
  • Terminal

それぞれのインストール方法は、公式ドキュメントに記載されています。

Atomの場合は以下のパッケージを入れます。
git-time-metric
※インストール後はAtomの再起動が必要です

初期化

プロジェクトごとに初期化します。

cd your/project/root
gtm init

以上で設定は完了です。
あとは普段どおりにコードを書くだけです。

比較方法と集計手順

3/14 - 3/20の1週間で、夜行バス比較なびの各issueにかかった時間を集計しました。

Toggl

f:id:lcl-engineer:20180416135145p:plain Web上のReports画面で期間を選ぶと、集計されます。 集計の単位は、clientとprojectが選べます。 現状は、clientには対応するサービスの名称(夜行バス比較なび、格安移動、等)、projectにはissue番号を入れています。

GTM

コマンドを打って出力します。

gtm report -format summary -from-date 2018-03-14 -to-date 2018-03-20

f:id:lcl-engineer:20180416142738p:plain

コミット毎に時間が出力されます。 今回は、issueごとに集計する必要があるため、この情報を使います。

なお、コミット毎の時間はわかるものの、issueをグルーピングする情報はコミットメッセージにつけた文字情報(issue番号)しかありません。 そのため、集計するためには文字列を解析する必要があります。 今回は、テキストエディタとGoogle スプレッドシートを駆使して手動で集計しました。

今回の集計では使いませんが、以下のコマンドを打つと、タイムライン形式で表示されます。

gtm report -format timeline-hours -from-date 2018-03-14 -to-date 2018-03-20

f:id:lcl-engineer:20180416144521p:plain ※ 印のついていない時間が多いですが、他のプロジェクトの仕事や開発以外の仕事をしている時間です。

集計結果

TogglとGTMの計測結果を表にまとめてみました。

ツール issueA issueB issueC issueD
Toggl 11 428 574 71
GTM 6 121 310 0

※単位:分
※小数点以下は切り捨て

結果にはかなり開きがあります。 GTMでは実際にコードを書いている時間しか計測できないため、以下のような時間が漏れているのだと思います。

  • ミーティング、他のチームやメンバーとのやりとり
  • 仕様確認や設計、ドキュメント作成
  • テスト、コードレビュー等

良いところ・良くないところ

結果をふまえて、それぞれのツールの良いところと良くないところをまとめました。

Toggl

良いところ

  • 準備が簡単。アカウントを作ればすぐに始められる
  • 計測が正確(ただし押し忘れなければ)
  • コードを書いていない時間も計測できる
  • Reportがいろいろな形式で見やすく、集計しやすい

良くないところ

  • 計測が手動(慣れないとボタンを押し忘れる)

GTM

良いところ

  • 計測が自動(ボタンを押さなくて良い)
  • タイムラインがおもしろい(Togglにもあるのかもしれないが見つけられず)

良くないところ

  • プロジェクトよりも細かい単位では集計するのが大変。issueごとに集計する場合は、自分で加工が必要
  • コーディング以外の時間が入らないため、短期間で見ると結構ずれがある

まとめ

今回は短期間(1週間)かつ細かい単位(issue単位)で比較してしまいましたが、GTMはこのパターンが苦手なようです。 もっと長い期間で大きな単位、例えば3ヶ月間でプロジェクトAとプロジェクトBにかけた時間の割合を比較する、といった用途ならGTMでも役に立ちそうです。

仕事に慣れるまでの方や、細かく記録したい方はTogglが向いていると思いますので、用途に合わせて使い分けるのが良さそうですね。

エンジニアブログ編集部の立ち上げとその目的

モバイルアプリエンジニアの山下です。

LCLでは今年からエンジニアブログ編集部を立ち上げました。
現在はフロントエンド、バックエンド、モバイルアプリエンジニアの3人で活動しています。

今回は立ち上げから3ヶ月が経過したので、立ち上げた経緯とその効果を紹介したいと思います。

エンジニアブログを運営する目的

LCLでは以下の目的でエンジニアブログを運営しています。

ブランディング向上

主にエンジニア採用を意識したものです。LCLは社名・サービスともにまだまだ知名度が低い状況にあるため、応募者からするとエンジニアとして働きがいがある環境であるか不安に思われる可能性があります。そこでLCLに興味を持ってくれた応募者に対して、「この会社で働いてみたい(働いてもいいかな)」と思ってもらうことを第一目的としています。

そのため、ブログを通じて以下の点をアピールすることを目標としました。

  • エンジニアがエンジニアらしく、働ける環境であること
  • モチベーションの高いメンバーがいること
  • 色々な技術・プロセスを幅広く習得できる環境であること

エンジニア界隈への貢献

業務を進める上でOSS・ドキュメント・検証記事など日頃から多くのアウトプットに支えられています。
LCLからも誰かに貢献できることを目標として継続的にアウトプットをするため、その一手段としてエンジニアブログを運営しています。

ブログ駆動開発

流行りの技術や業務改善を検証する際、その取り組みが有用と確証できないことが多いため後回しになりがちでした。また、業務として着手する場合は工数が無駄になってしまう可能性もあり、着手しづらいまま放置されていました。
そこで、ブログネタにすることを前提で取り組むことを予め宣言するようにしたところ、モチベーションと鮮度が高いうちに時間を割いて着手できるようになりました。

去年までの課題

LCLのエンジニアブログは2016年から運営されていますが、以下の課題がありました。

  • 更新頻度が不安定
    • 投稿する気はあるが後回しにしがち
  • 更新内容の領域が狭い
  • ブログネタが無い
  • 執筆者が少ない

LCLのエンジニアは日頃の業務から検証内容や手順などをQiitaなどでドキュメント化して共有する文化があります。それに、業務を進める上でネタがないことはありません。
つまり、書き手とネタは揃っていたためブログの運用プロセスが管理されていないことが課題だと判断しました。

エンジニアブログ編集部の目的

去年までの課題を踏まえ、先陣を切って執筆のサポートを行えば開発部全体として継続的なアウトプットが可能になると考えたため、エンジニアブログの管理を行う編集部を立ち上げました。

エンジニアブログ編集部として、以下の目的を定義しています。

  • 会社の名前で記事を書くため、最低限の質の担保
  • 継続的に記事を公開するために、強制力を持たせる
  • 個人ではなく、組織的に記事の質を向上する

会社の名前で記事を書くため、最低限の質の担保

やはり会社の名前で投稿する以上、個人で投稿するよりもセンシティブになります。
そこで、必要最低限のルールと執筆のコツをまとめた執筆ガイドラインを作成しました。

ルールの項目は次のとおりです。

  • 投稿内容は「技術・働き方」に関するものであること
    • 開発部合宿なら問題ないが、純粋な旅行日記などは相応しくない
  • 秘匿すべき情報を隠す
    • 記事中はもちろんのこと、コードやログの中にも含まれていないか確認する
    • Access Key / Token
    • Webhook などのURL
    • プロジェクト名
    • リポジトリ名
    • モデル / オブジェクトの構造
    • 社員の個人名 ..等
  • 法的、倫理的にグレーな内容を避ける
    • 画像関連の著作権違反に注意する
    • 特にスクリーンショットに紛れていることが多い
      • キャラクターの画像が使われている
      • 広告に俳優やアイドルが写っている
  • 否定しない
    • 否定すると炎上する可能性が高まる
    • もし否定する場合は個人の意見という旨を添える

以上のことに注意して、記事公開前は下書きを公開してチェックし合うようにしています。

継続的に記事を公開するために、強制力を持たせる

"強制力"というパワーワードを使っていますが、一方的に執筆を強制するという意味ではありません。
去年までの傾向から個人任せだと後回しにしがちになってしまうため、部員は互いに意識し合い(時には急かして)継続を絶やさないようにしています。

個人ではなく、組織的に記事の質を向上する

先にもありましたが、ガイドライン内のルールや誤字脱字などを公開前にチェックしたり、他職種の観点から良さそうなネタを提供することを全員で行うようにしています。 執筆者がタイトルや章、文中の図の構成に悩んだ際はMTGやチャット上で相談し合ったりしています。

エンジニアブログ編集部の活動内容

部活動として週に1回ランチMTGをしています。

MTGでは、以下のことをしています。

  • 先週の記事の振り返り
  • 参考ネタの共有
  • ネタ出し
  • ネタ整理・次回ネタの設定
  • その他

先週の記事の振り返り

現在は『継続的に投稿すること』を第一目標としているため、KPIや数字を掲げた目標は設定していません。そのため、振り返る内容としては流入元、はてブ数くらいです。数字の掲げ方は今後の課題になっています。

参考ネタの共有

直近で話題になった記事やはてブのホットエントリーなどをみて、LCLとしても書けそうな題材があれば共有しネタにするかを判断します。
ここからブログ駆動開発やモブプロのネタになることも多いです。

techblog.lclco.com

ネタ出し

ネタや進捗の管理はTrelloで運用しており、日々ネタになりそうなものは分野問わず「持ち込みネタ」へ追加するようにしています。

f:id:lcl-engineer:20180416141407p:plain

ネタ整理・次回ネタの設定

溜まったネタを誰が担当するかを決定したり、書きたい人がいない場合はボツにしたりします。 直近の作業と関連するネタが有る場合は、編集部以外のメンバーへ依頼することもあります。

「アウトライン」以降は原則1人1カードとなるようにしているため、記事を公開してカードが無くなったら個人の「ネタ」から取ってくるようにしています。

その他

上記の他にも、エンジニアブログのメンテナンスや関連するエンジニア採用の施策などを検討したりしています。
MTGはブログの進捗が無く、MTG内容が少ない時も「継続」の意識を絶やさないために原則行うようにしています。

効果

継続率、はてブ数共に良い結果がでています。

継続率

編集部員は2週間に1記事を目標に取り組んでおり、この3ヶ月間は順調に継続できています。(2月は短いので許容)

f:id:lcl-engineer:20180416141428p:plain

はてブ数

この3ヶ月間で4本の記事がはてブ50超えを達成しました。

はてブ100超え 記事一覧

techblog.lclco.com

techblog.lclco.com

はてブ50超え 記事一覧

techblog.lclco.com

techblog.lclco.com

おわりに

私自身入社前にこのブログを読んだことが入社理由の1つになっています。 直近でも他社の方や採用応募を頂いた方から触れていただく機会があり、やはり知ってもらう・興味を持ってもらう媒体としてエンジニアブログは有用な手段ではないかと感じています。

執筆側として多くのフィードバックをいただく際は開発業務とは別の達成感があります。

ブログ駆動開発でちょっとした課題に取り組みやすくなったり、ブログネタを通じて技術の話題をメンバーとフェイス・トゥ・フェイスで話す機会が増え、ブログを書くこと以外にもいい影響が生まれました。

今後はエンジニアブログを通して、エンジニアの繋がりなども確率できればと考えています。 これからも継続的に投稿をしていきたいと思いますので、購読お願いいたします。