July Tech Festa 2018に参加してきました #JTF2018
皆さま、こんばんわ^^
先日、2018/07/29(日)に産業技術大学院大学で開催された#JTF2018に参加してきましたー
台風が過ぎ去ってくれて本当に良かったo(^▽^)o
インフラに特化したカンファレンスってあまりない気がするので、インフラエンジニアの方々の目に留まってこのカンファレンスがもっと盛り上がればいいなぁって思ってレポート書かせて頂きました。 また、登壇者の皆さま、役立つお話を聴かせて頂き大変参考になりましたー
聴講しながらメモってたので間違いがあるかもしれませんが、その場合はご指摘いただけると嬉しーですmm
[A10] 組織の生産性を上げる役割「VP of Engineering」とは？
- 登壇者は三人で司会からのお題に対して答えていく形式
- 補足すると、@sak0620さん,@nari_exさんはVPoEを現在進行形でやっているが、@s_woolさんは2018/09に就任予定らしい（現在はエンジニアリングマネージャ）
登壇者
- メルカリ@sak0620
- ハートビーツ@nari_ex
- Gunosy@s_wool
Q: VP of Engineeringの立上げはどうだったか？
A: メルカリの場合
- メルカリは2017/4に2党体制になった（CTOとVPofEngineering）
- 100名規模になった時にグローバルで戦える組織を目指して責任と専門性を分離した
- Globalで200名くらいエンジニアいる
A: ハートビーツの場合
- ハートビーツは、もともとCTOが両方やっていた
- 組織規模拡大とマネジメントの負担増で限界がきた
- 必要にせまられた
A: グノシーの場合
- グノシーでは、CTOがもともと一人でやっていた
- 技術の責任、マネジメントの責任、事業の責任を一人でもつのは重たい
- 集中する役割を分散した
- くわしくは去年末のグノシーブログを！
Q: VPoEの役割について？（確かこんなお題だった気がする...）
A: メルカリの場合
- メルカリでは、技術はCTO、組織はVPoE
- CTOの理想はアップルのウォズ
- 技術のトップラインを引き上げるのはCTO
- エンジニアリングの責任を持つのはVPoE
- 範囲が曖昧であることが多い。CTOの成果を最大化するためには、隙間におちたボール広いをするのも重要な仕事
A: ハートビーツの場合
- CTOは、技術方針、社内開発、技術的な広報活動
- VPoEは、組織マネジメント、事業運営、文化の浸透、醸成
- お互いに得意分野に注力
- CTOは将来を見据えた技術の選定、その技術をもって事業にコミットする
A: グノシーの場合
- CTO→技術の幅
- チーム開発力→CTO+VPoE
- エンジニア層の厚さ→VPoE
- チーム開発力、メンバーの配置
- エンジニア層の厚さ、採用、目標設定とその評価
Q: VPoEという仕事のやり甲斐
A: @sak0620の場合
- マネジメントによるエンジニアリング組織の可能性の拡大
- 企業や組織の可能性
- エンジニアメンバー個人の可能性。
- エンジニアロールのキャリアの可能性
- 組織をマネジメントしていく中で、法則性を見つけた時
- どんどん伸びていくエンジニアをみて嬉しい
A: @nari_exの場合
- 一人一人の価値観を知ることができる→学びがある
- 責任範囲が広いので、どこでなにが起きても自分の範囲内なので納得感が高い→うまくいかなかった時もあるが、うまく言った時の貢献度も高い
- 組織マネジメントの原理原則を学び、実践するというサイクルを学べることが楽しい
A: @s_woolの場合
- 読む本が変わってきた。人事系の本
- エンジニア時代は、自身の成長にプライオリティをおいていたが、エンジニア組織全体のスケールアウトさせる視点にこだわりたい
- 自身の評価も自身で考える必要があるが、あるが、組織の成功=VPOEの成功としていずれ後任ができたときのサンプルになりたい
Q: わかってほしいVPoEの大変なところ
A: @sak0620の場合
- いろんな方面からくるリクエストがあるので、判断を誰かに降ったり自分で決めたりすること
- 信頼するけど、信用はしない。心を強く持つ
- 経営者にも伝えるべきことは伝える。が、それを真摯に対応するのは辛い（なびいた方が楽。。。）
A: @nari_exの場合
- 人の話題の引力が強く、意識をそこだけにフォーカスしがちで、他が停滞してしまうので、ある程度割り切る
- 他部署との関わりが激増するので、エンジニア同士の空気感で接して事故ると大変
- 接し方に苦労をしている
A: @s_woolの場合
- これからやっていく不安に関して
- マネジメントの責任があるとはいえ、フェーズ、規模感によって正解が変わるので寛容に変化に付き合ってほしい
- 人間同士のトラブルなども解決しないといけないと感じているので、心を強く持ちたい
Q: お互いに聞きたいこと
ハートビーツ@nari_ex→メルカリ@sak0620への質問
- Q: メルカリのスケールに対して、文化の浸透を難しいと思うので工夫をしていることは？
- A: 評価に組み込む、広報と連携する。組織の中でそこに貢献してくれるエンジニアをどうマジョリティーとしていくかは課題
ハートビーツ@nari_ex→Gunosy@s_woolへの質問
- Q: グノシーは、エンジニアの採用はどのような体制でやっているか？
- A: 採用担当もやっている。だれがどこの範囲を担当しているエンジニアなのか判断して採用にアサインしていくことで、ある程度の判断軸を人事(非エンジニア)に認識してもらう
Gunosy@s_wool→メルカリ@sak0620への質問
- Q: メルカリはスケールしているけど、全エンジニアと対話する機会を設けているか？
- A: エンジニアマネージャを増やして1on1を対応中。エンジニアマネージャはminiVPoE、テックリードはminiCTOみたいなもん
Gunosy@s_wool→ハートビーツ@nari_exへの質問
Gunosy@s_wool→みなさんへの質問
- Q: コードは書けてますか？
- A: メルカリ@sak0620: 平日はまったく書けてない。CTOに教えてもらう。休日の副業などで勉強している
- A: ハートビーツ@nari_ex: 仕事では12月から全くできてない。休日は学校にかよているので時間がない
メルカリ@sak0620→みなさんへの質問
- Q: 自身のVPoEの先のキャリアをどう考えているのか？
- A: ハートビーツ@nari_ex: 人の価値を上げていくことに。組織の連携を広げていけることに価値を感じている。バウンダリースパナー。どこかで一発当てたい
- A: Gunosy@s_woolの: エンジニアリングマネージャの組織拡大から会社全体をスケールさせていくことに興味をもっている
Q: 最後に一言
A: メルカリ@sak0620
- メルカリのVPoEを2年後に他の人に渡せたて、自分は別の部分でコミットできたらいいなあと思っている
- もっともっと成長したい
A: ハートビーツ@nari_ex
- エンジニアマネジメントをもっとみんなが重要視してほしい
- アメリカではエンジニアが5人くらいの組織でもVCがVPOEをおけというくらい重視されている
A: Gunosy@s_wool
- エンジニアがやりがいを持てる組織を作りたい
[A20] Site Reliability･Developer Productivity･技術戦略の取り組み
登壇者
- wantedly@koudaiii
発表資料
アジェンダ
- 変化に強いインフラづくりの結果
- マイクロサービスの課題
- 目指すゴールの変化
- どう解決していくか
内容まとめ
- wantedlyはいろんなサービスをやっているが、インフラチームはすべてのサービスの運用を担当している
- 前半はマイクロサービスを導入したことによる恩恵の話（組織のスケール,エコシステムの恩恵,運用の統一,リソースの効率的利用,etc...）
- 強力なコミュニティは世の中のアーキテクチャがどういう課題がありどこに向かっているのかわかるので、自分たちの向かうべき技術の指針になるという話（※重要）
- 後半はマイクロサービスを導入したことによる負債の話（変更時の影響が増大,エラーの複雑化,デバッグの難度上昇,ログ運用のカオス化,alpine辛い,etc...）
- 要はすべてをマイクロサービス化(kubernetesに搭載)してしまったことにより、運用面がカオスになってしまった
- マイクロサービスは、エラー、インシデント対応が難しい。インフラが抽象化されることで問題が見えづらくなる
- その中でも振り返りや情報共有会をしっかりやっているとのことで、私も見習いたいと思った
[A30] 明日から実践できる！運用自動化に必要な「テスト」にまつわる技術
登壇者
- あくしゅ@sparklegate
概要
運用自動化とは？
- 一般には手順をプログラムに置き換えることを指す場合が多い
- 人によっては勝手に運用されるということまで含めることもあるが今回の対象は違う
プログラムとはテストを要するものである
- 運用のプログラムが本番環境でどう振る舞うのかを事前に確認しておくべき
- ところが、本番環境と構成が異なる環境しかない。。。
- 運用プログラムの場合環境が異なっていてはテストにならない
ステップ
- 運用プログラム書く
- 運用プログラムをテストする
- 運用プログラムを本番環境で実行する
手段は？
- ツールはすでにたくさんある(ansible,chef,bashstep...)
- bashstepsは、手順的にbashを実行するツール github.com
テストのための本番環境をリプロデュースしよう
- オーケストレーションツールを活用する(Teraform,armtemplete,cloudformation...)
- マシンイメージをpackerなどで一式作成しておくとよい
- 自前でパッケージ管理してなければ、yumでそのうちpackageがinstallできなくなったりするので、イメージで保存しておいた方が安心感ある
- ビルドサーバも再構築可能にしておく
- Opsツールはツール単位でディレクトリをきって管理したりしている
- 本番環境と異なる構成のインフラは意味をなさない。。。
[F40] 「HCD（Human Centered Design）はじめの一歩」を学ぶ
登壇者
- 中央大学@iiojun
内容まとめ
- 人間中心設計
- 使う人の立場に立って設計する概念的なもの
- 「人間中心設計入門」という本を作った。第0巻
参考資料
[F41] CloudFormation+LambdaでAP基盤を自動構築した話
登壇者
- NJK@MUTOU YOSHIHITO
- NTTData@Toshiki Manaka
内容まとめ
- NTTDataではクラウドネイティブ化が進んでいる
- 社内のセキュリティルールに準拠していくためにPJT毎に自分で考えていかないといけないのでそこに課題感があった
- セキュリティ遵守しつつ、カスタマイズが可能な構成にすること
- 運用の利便性も必要だった
- セキュリティの苦労話
- なぜcloudforamtion and lamda使ったのか？
- エラー発生時に冪等性により再実行時にながーい待ち時間が発生する(cloudformationのみだと)
- amazon linuxでyum update失敗する。aws vpc endpoint経由でダウンロード可能になる
- cloudformatonのデフォルトテンプレートの値がサービスアップデートがタイミングによって変わるので、明示的に設定しておく必要あり
- ハイブリッド環境の場合はネットワーク的な制限をうける可能性があるので、要検証が必要
[F42] Web開発に関わる全てのエンジニアに知っておいてほしい、最近のフロントエンド事情
登壇者
- メルカリ@sottar_
内容まとめ
※フロントは知見が浅く、内容を理解するのに夢中になってメモとれず...申し訳ないです...。@sottar_さん資料公開してくれないかなー
[A50] ミランティスが1万台のサーバーを監視・運用するためにInfrastructure as Codeを利用している話
登壇者
- ミランティス@MMirantis(Machi Hoshino)
発表資料
内容まとめ
- @MMirantisさんは、アメリカ生活をしていたので英語は得意
- ミランティスはOpenstack専業ベンダ
- 入社時は少人数チームで世界各国の物理サーバ1万台を支えていることに驚いた
- 中途半端な自動化の落とし穴。自動化恐怖症（from Instructure as a codeに書いてある）
- 自動化の壁というものがある(手順書を中心とした運用、人離れが悪い。技術的な問題でメンテできないと昔の運用ままに...。)
- saltstackは、ansibleの良いところとchefの良いところがあったりしている
- ミランティスでは開発した運用コードを3つに分類(server level,system level,cluster level)
- saltstackによるコンテナ,VM,監視などの構成を徹底的に自動化
- Gerrit,jenkinsによるCI自動化
- パラメータシートは一切使ってない。全てはGitに書いてある（さよならexcel）
- service levelのコードは可能な限りsaltコミュニティへの開発を委託している
- ミランティスでは監視にprometheusを使っている
- endpointの設定ひとつひとつ書いたり,アラート設定項目をわすれるなどのミスをなくすために設定ファイルをsaltstackで自動生成
- 最近のネット記事など見ているとインストールの感動に比重が大きくなりがち、重要なのはそのツールが実運用に耐えられるかどうか
- ミランティスの答えは、infrastructure as a code + DevOps
- infra and apps are two different worlds.
- インフラエンジニアはアプリエンジニアが大嫌い！すぐにawsに載せたがる！インフラ運用作業の必要性を考えてない（完全にネタでしたwww）
発表後の質問編
- Q: ミランティスのエンジニアは何名？
A: 2桁のエンジニアでやってる
Q: テストも全て自動化しているか？
- A: HA系のテストは一部手動でやってるものがある
[A60] ソフトウェアで構築する成長し続けるインフラストラクチャとメルカリの挑戦
登壇者
- メルカリ@kazeburo
発表資料
内容まとめ
- 石狩DC--->TokyoDC計画が進行中
- 2018時点では,日本版はsakura+gcp
- メルカリインフラの歴史
- ngx_dynamic_upstreamのよる無停止、高速デプロイ
- RDSはbinlogをOFFれないのでEC2に載せた
- suggest機能で使っているsolarのindex dataを載せたdocker imageをconsul+dockerでdeployしている
※この辺でMac電池切れた...
