株式会社nanapiを退職しました。
個人的な近況報告です。 7月下旬を持って株式会社nanapiを退職しました。
2013年1月に4人目のエンジニアとして入社したので約2年半ほど在籍してたことになります。
在職中は色んなところに手を出していて主に
- nanapi.jpの開発(Rails化、Docker化、モヤモヤnanapiとか)
- IGNITIONの開発
- 継続的インテグレーションの導入、運用
- CTO室な業務(エンジニア組織のこと考えたりとか採用活動とか)
- インターンシップの運営
･･･とか、大企業ではあまり経験できないようなスピード感の中いろんな業務を経験させて頂きました。今年からはリードエンジニアという立場でチームや組織を俯瞰して見ることが増えて、様々な面で成長出来たなーと実感出来る日々でした。
辞める理由は大きくネガティブな理由はなく、自分の技術的な興味の移り変わりが大きな理由です。優秀な同僚が多く、切磋琢磨し合える環境で働くことができたのはとても感謝しています。
エンジニアの採用サイトがリニューアルしていたので、せっかくなので貼っておきます。 辞めた身でこういうこと言うのも変な話ですが、nanapiはエンジニア以外の人のマネージャ・経営層も技術に対して理解があるので、新しいことにチャレンジし続けたい人にはとても働きやすい環境なんじゃないかなあと思います。
ちなみにあまり表に出てなかったですが、1年ごとに5万円までデバイス端末を購入補助される制度とか、入社時に2万円までPC周辺機器を自由に購入できる制度とかもあったりします。
次はフリークアウトで働きます。Scalaを書くのでPhpStormもRubyMineも使わなくなりますが、引き続きがんばります。（もちろんIntelliJ IDEAは使う予定）
Wishlist貼っておきます。
IVS CTO Night & Day 2015 Spring powered by AWS Staff Report
これはなに？
6月10日〜12日で宮崎のシーガイアで開催された IVS CTO Night & Day 2015 Spring powered by AWS にAmazonさんと一緒にスタッフとして参加してきました。
スタッフという形ですが、発表やアンカンファレンスはほぼ全て見ることができました。めちゃくちゃ濃くて、そして心身共に疲れ果てた3日間でした。
同じようにスタッフ枠という形での参加があるかどうかわからないですが、今後同じような枠を頂いたときにエントリする人に「スタッフがどんなことするのか？」「IVS CTO Nightってどんな雰囲気なのか？」を触りだけでも伝えるということがこのレポートの目的です。
なお、具体的にどんな内容の発表があったかなどはAWSソリューションアーキテクトの篠原さんの以下のブログが参考になります。
【開催報告】IVS CTO Night & Day 2015 Spring powered by AWS
スタッフとしての仕事
Amazonさんが9名と、外部スタッフ(自分たち)が3名の合計12名。 基本的な大枠の進行やMCはAmazonさんが持っていたので、自分たち外部スタッフ3名で以下を分担しました。
- 受付関連
- LT/各発表のタイムキーパー
- LT/各発表のモニタ接続確認
- 会場移動時の誘導
- ビデオ撮影
開催がまだ2回目ということもあり体系だった形になっていないので、状況を見て臨機応変に動きまわることが大事だなーという感じでした。
いろんなパネルを固定したり、会場設営したり、マイク回したり、後片付けしたりetc... みたいな細々したことをやってました。
（余談ですが、2日目は一日中立ちっぱなしだったのでエンジニアになって始めて足が棒になる感覚を味わいました。感無量。）
3日間の流れ
初日は基本的にウェルカムパーティなので受付及び入り口の確認がメイン。稀にIVS(CTO Nightじゃない方)の方が間違って会場来てしまうことがあるので常に出入口を見ている感じ。
二日目は朝8時〜受付とかモーニングセッション準備とか。 基調講演とメインセッションが10時〜で60分くらいの登壇が4本くらい。 夕方からはアンカンファレンス形式で複数あるテーマのうち、自分が議論したいテーマごとに分かれてテーブルで話し合う形式。 19時半くらいからはCTO Nightパーティ二日目。22時くらいに解散。
三日目は朝8時半〜IVSのメインイベント(多分)のLaunchPad。 誰か一人常に受付にいる必要があるが、基本的にはローテーションで会場内の発表に注視。
11時〜午前中いっぱいTechPitchという形式の、CTOによる技術LT。 午後は各テーマごとのパネルディスカッション*4つ。 最終日は18時半〜CTO Nightパーティ三日目。最終日だけ会場が別で、受付に人が要らないので自分たちも混ざって他のCTOと少し話した。
印象に残っていること
スピード感
面白いなと思って一番印象に残っているのが2日目のアンカンファレンスの「エンジニアの交換留学」について。 元ネタは今年の4月に行われていたpixivさんとドリコムさんの社会人交換留学について。
このテーマの元にどう思うか、自分たちの会社だったらどうか、という話が繰り広げられていた。 かなりポジティブに話が進んでいたらしく、具体的にそのアンカンファレンスの参加者の数社で交換留学をやってみよう、 という結論を1時間の中で出して、具体的なタスク化まで落としこんでいた。
コードを書き続けている人が多い
CTOが約100名と言っても会社規模はバラバラで、エンジニアは自分ひとりという会社もあったりするのでコードを書いているのは当たり前な部分もあるが、上場企業とかエンジニア規模百人以上の企業のCTOでも今でも日常的に(そして業務外で)コードを書き続けている人が多くとても刺激になった。
最近なんだかんだ言いつつ本とか(あとゲームとか)ばっかでコードから離れ気味になっている自分への戒めになった。
CTOは超パワフル
一部のCTOを中心に夜二次会、三次会〜に行って、朝4時くらいまでカラオケした後帰ってきて、その後朝8時半のLaunchPadには普通に参加しててすごかった。
食べ物が豪華
宮崎牛のローストビーフとかステーキとか食べた。
まとめ
とにかく刺激の連続なので、特に現場のエンジニアこそ機会があれば是が非にでも参加すべき、というのが個人的結論でした。 刺激だけじゃなく、CTOが感じていること・考えていることの高さまで強制的に目線を上げることができる3日間なので、コードを書いている以上に得られるものはとても多いと思う。 (1日中気を張っているからめちゃくちゃ疲れるけど!)
現場からは以上です。
2015初夏のKindle散財メモ
初夏というよりもはやもはや真夏の暑さだけど。 Kindleで50%オフ、というか厳密には50%ポイント還元してたので久しぶりに散財した。 最近もっぱらオーディオブックばっかりであまり紙の本とか電子書籍読む習慣がなくなってるので暫く積ん読になりそうではある。
- 作者: James O. Coplien,Neil B. Harriosn
- 出版社/メーカー: 翔泳社
- 発売日: 2013/08/23
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
- 作者: Peter J.Jones
- 出版社/メーカー: 翔泳社
- 発売日: 2015/01/19
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
- 作者: 松尾豊
- 出版社/メーカー: KADOKAWA / 中経出版
- 発売日: 2015/03/10
- メディア: Kindle版
- この商品を含むブログ (8件) を見る
- 作者: 中島雅弘,富永浩之,國信真吾,花川直己
- 出版社/メーカー: 技術評論社
- 発売日: 2015/05/26
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: ジーンキム,ケビンベア,ジョージスパッフォード
- 出版社/メーカー: 日経BP社
- 発売日: 2014/08/12
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
なれる！SE12 アーリー？リタイアメント<なれる！SE> (電撃文庫)
- 作者: 夏海公司
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/12/20
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
- 作者: 酒巻久
- 出版社/メーカー: 朝日新聞出版
- 発売日: 2012/09/01
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- 購入: 1人 クリック: 1回
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2013/08/23
- メディア: Kindle版
- この商品を含むブログ (5件) を見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2015/05/22
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
CoreOS Meetup Tokyo #1 に参加してきた #coreosjp
参加してきたので個人的メモをまとめました。 k8sは自分で触ってなくて、調べながら聞いてたのでほとんどメモ取ってません。 最後に個人的な所感をまとめてます。
Opening & Overview of CoreOS (@deeeet)
CoreOSとは
Motivation
- インターネットのセキュリティを根本的に改善したい
- 常にソフトウェアをupdateを出来る仕組みを持つOS
特徴
- Minimal(シンプル)
- No package manager
- No language runtime
- Update System
- Omaha(OS自身のBlue-Green Deployment)
- Container
- Clustering
- Data Center as a Computer
提供している機能
- etcd
- 分散型KVS
- fleet(flt)
- 分散initシステム
- etcdで作ったクラスタに対してスケジューラ的に
- Rocket(rkt)
- AppC runtime
- flannel
- kubernetes
Latest News
- TECHTONIC
- CoreOS Stack + Kubernetes
- 商用パッケージ
CoreOS/Rocket (@mopemope)
RKT from Yutaka Matsubara
www.slideshare.net
rktとは？
- Application Containerを動かすためのもの
- 2つのコンポーネントを持つ
- Application Container Executor(ACE)
- Metadata Service
- コンテナ外にCredential情報を置く仕組み
キーワード
- App Container Image
- App Container Image Discovery
- イメージを配信するための仕組み
- App Container Pod
- Containerをひとまとめにする仕組み
- まとめて配信
- App Container Executor - Runtime
Manifest
- jsonで持つ
- pod manifestも同様
Dockerとの違い
Composable
- no central daemon
- docker formatではなく共通formatでupload/download
Security
- イメージを暗号化、認証
Image distribution
- rktはマニフェストがない、自由
rktでできること
- Application Container Imageをダウンロード
- Docker imageもDL化
- セキュリティ証明書
- コンテやなPodを立ち上げる
- 動いているコンテナの中に入れる(Docker exec的な)
- Private network
- private(NAT)
- bridge
- macvlan
- Metadata Service
CoreOS OEM on NIFTY Cloud (@higebu)
www.slideshare.net
- 爬虫類大好き
CoreOS OEMとは
- CoreOSをいろんなプラットフォームで動かせる仕組み
- Nifty Cloud
- Community-Supported Platformsの中
CoreOSのOEMをするには
- Community-Supported Platformsの中
- 自身のプラットフォームで動くイメージを作成するための修正をPRしてMergeしてもらう
- ドキュメントを書いてPRしてMergeしてもらう
OpenShift v3 でDockerのPaaSを作る話 (@jacopen)
www.slideshare.net
OpenShiftの機能
- Kubeternetes
- 適した場所へコンテナを配備(スケジューリング)
- Docker image指定してのデプロイ
- Multi Tenant
- source-to-image
- githubのURLからdocker buildしてregistryに送る→kubernetesが配備
- Request Routing
- HAProxy
- Trigger
- GitHub Hookとか
まとめ
- OpenShift3=Docker+Kubernetes+PaaSの機能
- PaaSとしてはまだまだ未完成
- 現時点ではβ
- 正式リリースは2015夏くらい？
OpenShiftの構成
- docker
- kubernetes
- PROJECT ATOMIC
- 今回CoreOSで動かした
CoreOS運用の所感 (@spesnova)
- CoreOS on EC2
- 画像リサイズのホストに使っている
- &ElasticSearch
デプロイ
- ELB配下でBlue-Green
ログ
- logentries
- systemdのjournalを全部送る
モニタリング
- Datadogを全台に
etcd / fleet
- 全部使っていない
- ダイナミックオーケストレーション
- リソースマネジメントは？
- 使っていなくてもメリットはある
- ホストマシン構築タスクはほぼない
- AMI焼く必要すらない
- コンテナとホストの分離が楽
自動アップデート
- 今はオフ
- 今は手動アップデート
- locksmith(依存でetcd)が必要
- etcdの安定運用が前提条件
遭遇した問題
- CoreOSがEC2でクラッシュ
CoreOS channel選び
- alphaは品質的にalphaではない
- アップデートの頻度を表している
- ただしalphaは致命的なアップデートもくる
やりたいこと
まとめ
Docker + Checkpoint/Restore (@kawamuray)
- Checkpoint/Restore(CRIU)を用いてコンテナの起動を高速化
Checkpoint/Restore(CRIU)
- VMのスナップショットみたいなイメージ
使い道
- Startup acceleration
- Live migration
使う目的
- 起動の遅いサービスの高速化
- リソースの効率の最大化
- n台のサーバで構成されるPaaSクラスタのサービスキャパシティの最大化
- かつ低コスト
Kubernetes on CoreOS (@ianmlewis)
Kubernetesとは？
- クラスタのマネジメントシステム
- 0.14.2 released
- 200over contributors
#### Labels - Podに対して付ける
Kubetenetes on CoreOS
- kubernetes-apiserver
- kube-controller-manager
- kube-scheduler
CoreOSで運用する際に考えないといけないこと (@harukasan)
pixivにおけるCoreOS
デプロイ
- fleetctlをキックしてquay.ioからpullしてデプロイ
- デプロイ職人によるローリングデプロイ
- コンテナの外の状態を気にする必要がない
- 依存関係をOpsではなくDevの人が管理できる
モニタリング
- dd-agent
なぜCoreOSを採用したか
- アプリケーショの依存管理をコンテナ内に閉じ込めたかった
- コンテナしか動かさない運用をしたい
- なるべく状態を気にしたくない
- Immutable
- コンテナの状態は変えない
- Disposable
- コンテナをいつでも捨てることができる
CoreOSをどう捉えているか
- コンテナをいつでも捨てることができる
- Immutable
- systemd + etcd/fleet/docker
- サービスの管理はすべてsystemd
- だいたいのことはsystemdがやる
- fleetを使ってデプロイ
- 開発時のDockerコンテナを動かすインスタンスとして便利
CoreOSを使う上で考えないといけないこと
- 外部に依存しない状態を作るか
- まだうまい方法が見つかってない
- デプロイメント
- fleetだとローリングリスタートできない
- 自前でスクリプトを書く必要
- fleetだとローリングリスタートできない
- システムオーケストレーション
- fleetでできるのは「このsystemdのサービスをクラスタ内でいくつ動かすか」
- このサービスメンバをオートスケーリングとかは管理できない
- kubernetesならできそう
- fleetでできるのは「このsystemdのサービスをクラスタ内でいくつ動かすか」
- etcdにおける最小構成
- 最低4台
- 3台だと1台落ちるとスプリットブレインが起こる
- コンテナに対するロードバランシング
- モニタリング
- ログ転送
- 各ノードにtd-agentを立てている
- ※CoreOS上にtd-agentインストールして動かしてるっぽい？
- 障害対応
- 今のところホスト依存の障害は遭遇していない
個人的所感
- rktはimage distribution周りの自由度が高い分、本番運用を考えた時にイメージの取り回しや配信でとても悩みそう
- CheckPoint/Restore(というかCRIU)の話、色々すごすぎてついていけなかった
- Kubernetes周りは自分で触ってないのでほとんどついていけず... いきなり本番で使うのは厳しいっていう話を @spesnova さんも話していた。とはいえうちもずっとCapistrano使い続けるのはどうなのかなあっていう感じだったので試してみる。
- DevとOpsをいい意味で分離という切り口は確かにとてもおもしろい。今までDockerを触ってこなかったエンジニアへのアプローチにもなる。
- そういえばうち今CoreOSはalphaチャンネルのもので動かしてた。@spesnovaさん曰くCoreOSのチャンネルは現状beta使うのが良さそうとのこと。チャンネル周りはalphaもstableも一長一短で消去法的にbetaしかない、っていう現状が結構つらみ。
IGNITIONチームの開発フローについて話してきた #nanapi_study #hatenatech
こんにちは！だいぶ久々の投稿です。
今週は台風18号、来週は台風19号が来ていますが、そんな台風の合間を縫って東京と京都の勉強会で話してきました。
nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー - nanapi勉強会 | Doorkeeper
【nanapi x はてな】はてなとnanapiの開発フロー in Kyoto - connpass
ブログを書くまでが勉強会！既にこれらの勉強会についてのまとめはいくつかブログが上がっていましたので、このエントリでは懇親会で話したり聞かれたネタとか、スライドの補足とかを諸々書いてみます。
物理カンバン廃止について
最初は物理カンバンを使ってタスク管理してましたが、途中からIGNITIONチームでは物理カンバンを使わない、という選択肢を取りました。
理由としてはいくつかありますが、一番の理由は「管理が面倒＆無駄が多い」っていうところです。 バーンダウンチャートを作るなりログに残すにしても結局別のタスク管理ツールとの二重管理が必須になってました。
あと、振り返りMTGをやるときにも物理カンバンを別の会議室まで引っ張って行くのも正直面倒というのもあります。日々の開発の中でだるいなーと思う箇所を排除したい（という意識を共有できるメンバーが多い）チームだったのでそういう選択を取りました。
もちろん物理カンバンの一覧性＆視認性は捨てがたいところではあるんですが。 リモート開発をいつでも出来るような環境を想定した開発フロー選定、というのもちょっと意識しました。
Jenkinsを使わない
語弊がありそうなので最初に書いておきますが、Jenkins自体はとても良いツールだと思いますし、nanapi.jpや他サービスの方では一部では現在も使っています。
が、IGNITIONチームではJenkinsは使わない、という選択肢を取りました。 理由としてはいくつかあって
- メンテコストが非常に高い
- 属人性が高くなりすぎる
- 社内のメンテナが固定されがち
- 結果、各ジョブが秘伝のタレ化する
- 社内のJenkins職人（通称Jenkinsおじさん）しかメンテできない
というのを問題視しています。
個人的意見ですが、クックパッドさんのデベロッパープロダクティビティ のように、それらをミッションとした専属チームがメンテをし続けられるのであればJenkinsも良いのかなあと思っています。
nanapiの規模だと個人が管理し続けるのはとてもしんどいので、そういったジョブはすべてSaaSに寄せる方向で検討している、といった感じです。
PhpStormの話
とりあえず言いたいことはすべて去年のPhpStorm Advent Calendarに書きました！
IntelliJ IDEAとかRubyMineでもPHP周りの独自機能を除けば基本は同じなので、ショートカットとか便利機能とか参考にして頂ければと思います。 全部読むのだるい方は、とりあえず25日目の記事を見ると大体幸せになれます。
ちなみに今年はAdventCalendarは書かないです。（予定）
Mackerelチームについて
発表者の id:motemen さんの記事が参考になります！
開発フローに正解なんてないので、気に入った＆チームに合いそうな部分を取り入れていけば良いのかなあと思います。
うちでは早速 Mackerelチームの 式次第 のやり方を振り返りMTGに取り入れてみました。
関連リンク
nanapi勉強会vol4でパネリストしてきた | おそらくはそれさえも平凡な日々
「nanapi勉強会 vol4」に参加してきました - 勉強会ログ
ちょっと面白いプラグイン Referencer
今日見つけたちょっとおもしろプラグイン。 http://plugins.jetbrains.com/plugin/7104
- Ctrl+Shift+Alt+C, Ctrl+Shift+Alt+C
- Ctrl+Shift+Alt+V, Ctrl+Shift+Alt+V
とかで動きます。
それぞれ、
- 現在のファイルから、いい感じの文字列を選択してクリップボードにコピー
- 現在のファイルから、いい感じの文字列を選択して貼り付け
が出来たりします。
具体的には、現在の時刻とかUnixTimeとか、現在のファイルパスとか開いてるファイルパス一覧とか、ファイル内の変数とかメソッド名とか、コード内のテキストとか色々取ってこれます。
絞り込みできないからあんまり使い道思い浮かばないけど、ちょっと使ってみる。
PhpStormからPull Requestが発行出来るよー
PhpStorm7からの新機能。
Find Action -> Create Pull Request から、Pull Requestが発行出来るよ！
OKすると、
こんなポップアップ出るので、リンククリックでGithubに直に飛べます。
PhpStorm内で完結できることが増えましたね！超便利。
