「ベンチャーCTO、AWSエバンジェリストを経て考える、クラウド時代に向き合うエンジニア像のこれから」参加レポート #jtf2015

スライド

www.slideshare.net

自己紹介

  • 堀内 康弘

経歴

エンジニアのキャリアの悩み

  • エンジニアvsマネジャー
  • 大手vsスタートアップ
  • 一社vs転職
  • どんな技術を学べば良いのか?

エンジニアの心構え

1. 変化を楽しむ柔軟性を持とう

  • 「コンピュータが家に来る時代なんてこないよね」と言われていた
  • iPhoneという500ドルのものが売れるわけがないだろ」→売れた
  • FlashHTML5についてのイラスト(2001-2015)
    • f:id:nihonbuson:20150726200655j:plain
  • 未来の予測なんてできない。でも変化は常に起こり続ける
  • 主要な変化は技術革新。
  • 技術革新で今までより楽ができるようになる
技術革新→時間ができる→新たな技術革新の例

技術革新を起こし続けるAWS

  • AWSのサービス数は45以上に
    • 現在、46個のサービスがTOP画面に表示されている)
    • インフラの上に使われるアプリケーションまで提供している

AMAZON RDS

  • マネージドRDBMSサービス
  • AWSがDBを立ち上げてすぐ使えるようにするサービス

AMAZON AURORA

  • MySQLと同じように扱える
  • 可用性・耐久性が高い
  • スケールアップ・スケールダウンするときに止めないようにできる
  • フルマネージドしてくれる
    • エンジニアはアプリケーションのみ集中すれば良い

AWS LAMBDA

  • サーバの運用をやってくれる
    • お客様からサーバーの概念を無くす
  • イベントに対応するコードを用意するだけ
    • 例えば、S3に画像アップロードすれば、適切な画像サイズに変換するなど

AMAZON API GATEWAY

  • API作成支援サービス

サーバーを用意することなくAPIが作れる

  • デバイスからアクセス
  • API Gateway(インターフェース)
  • Lambda(ロジック)
  • DynamoDB(データ保存)

  • 新しい技術を楽しもう!楽をしよう!

2. 楽しいと思ったものにのめり込もう

  • 強みがあると強い
    • ○○の○○さん
  • 発表者(堀内さん)の場合

3. 技術は手段であると心得よう

  • 技術を目的にすると間違った方向に陥りがち
  • 技術はなくなるかもしれないが、ビジネス課題は無くならない
    • 課題を解決するための技術
  • 価値を提供するのが主。手段はなんでも良い

ダメな例

  • 問い合わせフォームにSledgeを利用
  • 1台の物理サーバ内でロードバランサー+2APPサーバー+DBサーバー
  • まず自動化ありきのクラウドによる自動化
    • アプリケーションチームを分ける→疎結合するためにAPIを使おう→API Gatewayの利用
  • ゲームの基盤を作って共通化しよう(ガチャチームを作ってガチャモジュールを作ろう)
    • エンジニアのモチベーションが下がってしまった
    • 課題として魅力的ではなかった
    • 全体的に非効率になってしまった
  • マイクロサービスが流行っているからうちのサービスもそうしよう
    • 疎結合にすれば開発効率・メンテナンス性が上がる?
    • 1人や2人の段階だと、システムが複雑&メンテナンス性が大切

良い例

  • ゲームタイトル毎のチーム編成(gumi時代)
    • それぞれにディレクター、エンジニア、デザイナーを配置
    • チームの目標はゲームの売上の最大化
  • アマゾンはPRドキュメントをまず最初に作る
    • お客様の課題を解決することが第一だから
    • 「このような発表ができることを嬉しく思います」
  • ○Aの部分は、更新頻度が高いので切り離して疎結合に構成して連携するようにしよう

価値を提供することが前提

  • インフラエンジニアだからインフラしかしません→その技術が廃れてしまったら…?
  • WEBエンジニアの価値を上げていきたい
    • インフラのことを知ればエンジニアの範囲を広がる→エンジニアの価値が上がる
    • 技術を持つ=エンジニアの価値が上がるわけではなかった

4. いけてるアニキや仲間を見つけよう

僕が出会ったイケてるアニキ・仲間達

  • Parlの神様、宮川さん、伊藤さん
  • 明確なビジョンで突き進む起業家、間下さん、国光さん
  • ビジネスのイロハを教えてくれた天野さん
  • 圧倒的なスペックで常に前向きな玉川さん
    • 弱音を聞いたことがない
  • 刺激を受けて生きてきた

どうやって出会うのか

  • コミュニティに参加する
  • イベントで登壇する
    • 参加するだけでなく、登壇することで話に関われる
    • アウトプットし続けることが大事
  • 大学や会社で出会う

まとめ

  • 変化を楽しむ柔軟性を持とう
  • 楽しいと思ったことにのめり込もう
  • 技術は手段であると心得よう
  • いけてるアニキや仲間を見つけよう

最後に

  • 実際にすぐにアクションを起こすために
  • スタートアップのCTOになると、これらが自ずと身につきます
    • 毎日が変化の連続
    • 技術の決定権あり
    • ビジネス課題の解決を考えざるを得ない
    • CTO繋がり、登壇機会
  • なぜCTOになったか→他に誰もいなかった
  • 募集サイトにも340件のCTO募集があった
  • CTOになろう
    • 給料も結構もらえるし
    • チャレンジするのにそこまでのリスクはない
    • Let's チャレンジ!

質問

Q. 使ってもらえるためのAWS LamdbaでサーバーOSの運用のメリットがあれば教えてください

    1. AWSは組み合わせて使うもの
  • WEBサーバー立ち上げて…という作業がLamdbaを使うだけで良い
  • DynamoDBをすぐに採用しない理由として、作ってきた経験、ライブラリも揃っているので方法論がすでにあるからだと思う
  • これまで書いているプログラムを載せ替えるのは大変
  • 苦労していくのが無くなるならば、Lamdbaに載せ替えていいと思っている

Q.「ビジネス解決をするために技術がある」と仰っていましたが、技術がなかった場合のアプローチ方法は?

  • 人に聞いたりググったりする
  • 色んな課題はある
    • mixiアプリを出したらすぐにアプリケーションが落ちた
    • 問題に直面すると必死になった身についた
  • 解決できない課題はない
  • 絶対無理だよなと思っていても解決できる
  • 苦しみを楽しもう

Q. 国光さんなどの経営者との話し合いで決定する際に、腹を割って話す環境づくりの方法は?

  • そもそも国光さんとは飲み仲間だったので、話が普通にできた
  • 相手に話をしてもらえるようになるには、常にニコニコしていること
  • 「エンジニアは特殊な人だから話しかけにくい」という印象を無くす
  • その組織づくりをしていくことが大切

感想

  • 最後はまさかの「CTOになろう!」という発言w
  • 「技術は手段である」という言葉は完全に同意です
    • 問題があるから、解決策が必要になる。その解決策として新たな技術。
    • 価値を提供したいから新たな技術を採用する。
  • 変化を楽しむってとても大事だと改めて感じました

JTF2015講演まとめ

nihonbuson.hatenadiary.jp

「マイクロサービスで、一歩先行くImmutable Infrastructureを目指そう」参加レポート #jtf2015

スライド

www.slideshare.net

発表者のブログ

oshiire.to

自己紹介

  • しょっさん
  • 「よくここのアイコンとここの名前でここに来たもんだ」

今回の発表について

  • 紹介ページが他の人と比べておかしい
  • 色々訳あってスポンサーすることになって会社名を出せない
  • 抽象的な話ばかりになっちゃうことになる
  • 期待と違いがあったら「最悪だった」と言ってください

今日の内容

  • 明らかに人を呼びこむタイトル
  • 今日の発表の主体はマイクロサービスではなくSevice Oriented Architecture(SOA)の話

Immutable infrastructure

  • 既存のものはそのままにしておいて、新しいものは使い捨てできるようにしよう
    • 日本だけしか流行っていない

Blue Green Deployment

  • 新しいものはGreenに入れよう
  • ある程度揃ったら切り替えれば簡単だよね
    • 元ネタのブログは最近は絵が変わってた

Issues

  • しかし現実は様々な問題がある

1. Stateless and stateful services

  • Statelessなサービスは、情報が無くなっても良い(問題ない)
  • DBサーバーはどうするのか?
    • ある程度の更新を止めるのか
    • DBは別の方法にする?
  • 単純なシステム構成なんて無い

2. Complex System

  • サーバーのやり取りが複雑すぎる
    • 銀行のサーバーを一度見てみると良い
    • 青い銀行はいっぱい募集している
      • 今なら三行分のシステム構成が見れる
  • 交換するときの影響度が把握できない

Microsevices

  • 2014年3月に提唱
  • James Lewisが提唱しているが、Martin Fowlerのブログで書いている

特性

  • いっぱい特徴がある
  • コンポーネント
  • プロダクト(プロジェクトではない)として提供
    • プロジェクトのように、1回作って終わりではない
    • 開発した人が責任をもって運用し続ける
  • スマートエンドポイント
  • コンポーネントを簡単な手順で結びつけろ
    • RESTを使う(同期)
    • Message Queueing(非同期)
  • 分散して統治する
    • 自分達で責任をもって管理する

コンポーネント

  • 役割分担とインターフェースの明確化
  • 活性保守の仕組み作り
  • メモリはコンポーネントの一つ
    • マザーボードに指す順番が決まっている
    • メモリを変えれば、メモリのサイズを上げられる
    • インターフェースは変わっていない
    • インターフェースが明確でないとこんなことはできない
  • コンポーネントを使う人は変更を知らなくて良い
  • 「機能が削減された」「ロジックが変わった」はダメ
  • コンポーネント化すると、コンポーネント単位で区切れるので、コンポーネント毎に切り替えられる
  • マイクロサービス化されていれば、ステートレスなサーバーに、インターフェースが変わらない保証があれば、適用できる…はず

Microservicesを始めてみよう…どうやって?

  • 日本は既にマイクロサービスしやすそうなところばかりが事例として載っている
  • 欧米の紹介はよくわからない

僕達にはSOAがある

  • SOAのコンセプトがだいたい一緒
  • 事例もある
  • SOAの事例を使えば、Microservicesにも使えるのではないか
  • 外国ではSOAの話題が更新され続けている

アプリケーションフロントエンド

  • エンドユーザーとの対話部分
  • バッチなどからコールされるプロセス
  • 人とかプログラムの境界部分

サービス

サービスレポジトリ

  • 提供されているサービスの情報を集約
  • 使う人が分かるように

サービスBUS

  • 接続性、技術、通信概念の混在
  • 技術的なサービス
  • 各々のサービスをBUSを通じてコミュニケーションしよう

SOAの目的

SOAとマイクロサービスの比較

  • SOAは集中、マイクロサービスは分散
  • SOAは集中→分散管理、マイクロサービスは分散管理
  • SOAは大企業向けトップダウン、マイクロサービスは中企業向けボトムアップ
  • 企業の規模、企業の風土に合わせて適用することが大切

SOAロードマップ

  1. 基礎段階:保守性の向上
  2. ネットワーク化整備:柔軟性の向上
  3. プロセス制御段階:俊敏性の向上

基礎段階

ネットワーク化段階

カプセル化
テクノロジゲートウェイ
  • ECサイト、配送システム、B2Bポータルと別々の入力があっても中堅層を通じて基本層に行う
中堅層を使えるようにすると
  • データの拡張
  • 引き継いだモデルを変更せず、レガシーアプリケーションのデータモデルを拡張
  • パッケージに対して機能を拡張する
  • 既存のプロトコルを維持、新たなクライアント機能を追加

プロセスの制御

  • プロセスのカプセル化
  • ECサイト→予約プロセス→会員、受注・在庫の中堅層→受注、在庫
  • 単純化
  • プロトコルが要らなくなってきたら中堅層をなくしていく

中堅層の考え方

  • 複数のプロセスが利用する場合に中堅層を作る
  • プロセスの中心化

プロセスの中心化

  • なぜプロセス化したいのか
  • 簡単にプロセスを組み合わせて新しいサービスを提供したいから
  • サービスもUIもあれば、プロセスを作れば簡単になる
  • セッションを長時間維持するためにもある

summary

  • サービス化:疎結合→影響の極小化
  • 適合可能な技術の選択
  • 新しいものと古いものを組み合わせる
    • 新しいものが全て良いとは限らない
    • 古いものが悪いとも限らない
  • 車輪の再発明はしない
  • 再利用しよう
  • Re-usable But Re-cycle
    • はじめから再利用しようと考えるものと、あるから使おうは違う
  • 流行に流されないようにしよう
  • SOAをもっと知りたい人は『SOA大全』を読もう

SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針

SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針

感想

  • マイクロサービスではなくSOAの話でしたが、すごい楽しんで聞くことができました
  • 「マイクロサービスとSOAって何が違うの?」と聞かれると言葉に詰まっていましたが、腑に落ちる説明でありがたかったです
  • メモリの話とか分かりやすかったです
  • SOAのロードマップとかRe-usableの部分とか、設計をしっかりと考えることが大切だと改めて感じたセッションでした

JTF2015講演まとめ

nihonbuson.hatenadiary.jp

「エンジニアのスキルパターンを作ってみた話」参加レポート #jtf2015

スライド

www.slideshare.net

自己紹介

DMMについて

  • サービスはどんどん増えている
  • サービスが増えて、会員も増えると、人員が欲しくなる
  • そこで、インフラチームで働くにあたって必要なスキルを調べてみた

ワークショップを行います

  • 調べてみた必要なスキルを使ってのワークショップを行います
    • 自分が身につけてるスキルに○
    • 自分が身につけたいスキルに☆
    • 歩きまわる
    • 自分が☆、相手が○となっているスキルについて聞いてみる
  • このワークショップは眠気覚ましにやってみた

DMM.comラボ インフラチーム スキルパターン ver.0.9

良い資質

  • 頑強な価値観
  • 旺盛な好奇心
  • 情報インプットのための努力
  • 素直で嘘を付かない
  • 強い責任感
  • 強い改善意識
  • 心と身体の健康
  • 知識を自分自身のものとする
  • 基本的技術を正しく理解している
  • 業務上必要な情報を把握している
  • 隣接分野の知識を持っている
  • 目標となる人がいる
  • 整理されたドキュメントの作成能力
  • ロジカルな思考
  • ファシリテーション技術
  • 外国語を操る
  • リクルーティングできる力

リーダーの資質

  • 下を守る楯となる
  • 部下の成長を考える
  • 属人化を防ぐ
  • 適切な権限移譲を行う

仕事に取り組む姿勢

  • 慎重に作業をする
  • 失敗を怖れない
  • 失敗を共有し対応を行う
  • 真実を探す
  • 分からないことは聞く
  • 遠慮しない
  • 仕事を自分で見つける、仕事を奪う
  • 背中を見せる。やって見せて説明する。
  • 知っていることを発信する
  • まずは手を動かしてみる
  • チャレンジする

仕事のノウハウ

  • 最初に目的をはっきりさせる
  • 目的に合った作業をする
  • ログを残す
  • 依頼元を巻き込む
  • 工数を意識する
  • 余裕を持つ
  • 先手を打つ

コミュニケーション

  • 柔らかいコミュニケーション
  • 大声を出さない、怒らない
  • 積極的な声かけ
  • スルー力

デザインパターン

パターンは形(かた)である

  • 臨機応変な対応もできる

デザインパターンの作り方

  • テーマを決める
  • パターンの種を集める
    • コンテキスト、プロブレム、ソリューションのポイントで書いていく
    • 数人単位でヒアリングして、付箋で書き起こし
      • 新人や隣の机に座っている人向けに求めるスキルは何か?
      • トラブルや障害事例の解決するためのスキルは何か?
      • このスキルが素晴らしいという人がいる?
      • 改めて新人向けに求めていくスキルは何か?
  • KJ法で分類
    • カードの距離感を考えながら分類していく
    • パターンの表層的な部分だけでなく、その裏側にあるところを考えられる
    • 今回のワークショップの題材は分類するのに1週間かかった
  • パターンに名前を付ける
  • グループした自称について以下の3ポイントを考える
    • Context
    • Problem
    • Solution
  • リバイス(見直し作業)
    • 抽出されたパターンが本当に価値なパターンを考える
    • 今回のものはまだリバイスできていないのでver0.9にしている

パターンの嬉しいところ

  • パターンには名前が付けられている
  • Contextが記述されている
    • 間違った適用・濫用を防ぐことができる
  • 人の成長を助ける
    • 良い物を抽出されている
  • 人にやさしい
    • マニュアルは読んでて面白くない
  • 失敗もアンチパターンとして記述できる

スキルパターンをどう現場で使うか

  • 自分の立ち位置を把握できる
  • チーム内コミュニケーションに
  • キャリアアップ、人事考課に活用できる?
  • 採用に使える?

パターンを使った成長イメージ

  • それぞれのパターンを評価していくことで成長を実感できる

質問

Q.ヒューマンスキルが多く並んでいて、技術系のネタが無いように思われるが、なぜ無いのか?

  • 技術系のネタがあまり出てこなかった
  • 基本的なスキルが理解してれば良いという意見が多かった
  • 情報インプットを努力することができれば良い
  • 面接で聞く必要スキルは現場はそこまで求めていないのかも

Q.スキルセットについて議論したことがあったが、専門知識と業務知識と社会人として当たり前の能力に分けられる

  • 入射する人に求めるのは社会人として当たり前の能力
  • 「分からないことは分からないと言うこと」がなかなかできないことが多い
  • 業務知識は社内でペーパーを作れば良い
  • 職場によって傾向が変わってくる

Q.パターンは評価に使ってないが、作る前後で何か変わったのか?また、個々人であるなと感じられるが、チームでは共有できていないのか?

  • パターンの種を集めたのが6月末、形になったのが1週間前なので…
  • プレ版は社内で行ったが、一人ひとりの視野が広がったと思う

Q.スキルを身につけないといけないと思うが、評価の基準はどうすれば良いか?

  • 360度評価にしたいが、柔らかいコミュニケーションが無いと評価されないから難しいと思っている
  • 多分、人事評価で使うと、まずい方向に行くと思う
  • チームとして足りないところを補填するために使ったほうが良い
    • この部分のスキルがある人がチームにいないので、募集するなど
  • 今期の目標を自分で決めて、達成できたか見返す程度に

感想

  • 実際にワークショップを通じてスキルパターンを自分に当てはめてみましたが、自分を見返すことができました。
  • ワークショップで数人の方と意見交換をしましたが、皆悩んでいる部分は似ていて、「失敗を怖れない」「属人化を防ぐ」の2つは☆(自分が身につけたいスキル)が多かったです
    • 保守段階のインフラにとって、現状を維持することというのは大切なんだなと共感しました

JTF2015講演まとめ

nihonbuson.hatenadiary.jp

「OWASP Japan ― 情報セキュリティとのうまい付き合い方 ―」参加レポート #jtf2015

スライド

speakerdeck.com

自己紹介

  • 石切山 開
  • セキュリティの関わりが学生の頃

OWASP

  • Open Web Application Security Projectの略
  • セキュリティ向上やセキュアなWebサービスの展開を目的として設立された
  • ツイッターアカウントは@owasp

OWASP Japan

  • ドキュメントのローカライズ
  • 日本独特な文化にどうセキュリティを結びつけるのか
  • 最近、関西や九州に支部を設立した
  • ツイッターは@OwaspJapan
  • ブログも始めた

情報セキュリティとのうまい付き合い方

  • 難しい
  • 何されているかわからないから怖い

突然ですが

  • 夏風邪が流行っているらしいです
  • どんなことをしますか?
    • 予備知識
    • 手洗い・うがい
    • 健康診断・人間ドック
    • 市販薬
    • 普段からの体力づくり
    • 生活習慣の見直し
  • 普段通りに健康に生きていく→予防する→それでもダウンする

情報セキュリティでも同じ

  • 普段通りに運用を継続する、普段通りサービスを提供する→予防する→それでもダウンする
  • でもセキュリティはよくわからないし…
  • 風邪については対策を当たり前にやっていますよね?

  • セキュリティの世界では

    • 作る人
    • 攻める人
    • 守る人

攻める人

  • 用意周到
  • 緻密な準備
  • 巧妙な手口
  • かけている時間と熱意がすごい

作る人・守る人

  • 運用でカバー
  • ドキュメントなんてものはない(ソースを読んでくれ)
  • とりあえず動くもの
  • かけている時間と熱意があまり無い

当たり前にすれば良い

  • 予備知識→OWASP Top10
    • 最も注意すべき脆弱性Top10とそれに対する対処法を説明
    • 影響度・深刻度を示している
    • 3年に1度リリース
  • 手洗い・うがい→OWASP Cheat Sheets
  • 健康診断・人間ドック→OWASP XAP
    • 脆弱性の診断を行うツール
    • 実行ボタン1つで簡易な診断が可能
    • 無料で利用でき、日本語にも対応
  • 通院治療・お医者さんに相談→イベント
    • オワスプナイトを実施
      • プレゼンやLTを踏まえたカジュアルな勉強会
  • 生活習慣の見直し→OWASP Dependency-Check
  • 詳しくはメーリングリスト

まとめ

  • 健康は1日にしてならず
  • 運用の苦労は皆さんの方がご存知
  • 当たり前って大事
  • 誰もが安心して使えるWebの世界を目指して

緊急告知

  • 明後日、オワスプナイトがあります
  • 現在キャンセル待ちですが、特別招待券が10枚あります
  • 会場にてご相談を

感想

  • 夏風邪を使った表現が分かりやすかったです
  • Jenkinsのプラグインなど、当たり前にしていく試みは是非とも取り入れてみたいと感じました

JTF2015講演まとめ

nihonbuson.hatenadiary.jp

「外部サービスを使わずにPullRequestベースの開発をするために行ったこと」参加レポート #jtf2015

スライド

www.slideshare.net

自己紹介

2010年の社内環境

  • Trac and hiki and subversion
  • Ruby 1.8.7
  • Gitが浸透していく時期だった
  • 制約上、プログラムを外に出さない
  • 外部のChat使用は禁止
  • Tracでチケットを見ながら、Subversionに上げていく
  • 内部に入れるのは正社員のインフラのみ
    • アプリケーションエンジニア「Deployお願いします!」
    • インフラエンジニア「今からDeployします!」
    • アプリケーションエンジニア「Mergeお願いします!」
    • インフラエンジニアもしくはPM「Mergeが大変…」

問題点

  • タスクとソースで2つのツールを行ったり来たり
  • SubVerisonなので中央管理なので、コミットにrefsをつけないと個人のコミットが状況が追えない
    • グラフ表示がない
    • ログを追うしか無い
  • インフラもしくはPMがMerge地獄にあう
  • プロジェクト毎にブランチを切っていたら100位上のブランチ数に…
  • Deployする人が限られている
  • スピードが遅い
    • Mergeに時間が掛かる
    • Deployを依頼するのが面倒
    • Commitをミスすると、みんなに連絡してrevertしてのコストがかかる

選択する上で大事にしたこと

  • イラッとする部分を解決したい
  • ワクワクする
  • 世の中を見てお作法的になっていることは取り入れたい
  • プロダクト毎に最新を提供

GitLab導入

  • 無料でサクッと試す
  • Gitに慣れるためにペアオペ
  • 当時、Pull Requestの良さを知らず、使い方はSubversionと変わらず

リモートリポジトリの安定

  • 個人でcommitを重ねて行えるように
  • 壊す心配が減った
  • ただし運用がそのままなので、gitに詳しくなっただけだった

ALMiniumの導入

  • サーバーの突然の死
  • マイルストーンの設定などがTracに比べて見づらかった
  • 2013年ごろに盛り上がっていたRedmineやJenkins同封のALMiniumを導入した

システムの統一

  • wikiとチケットがひとつになった(wikiとticketの横断検索ができるように)
  • リポジトリのグラフ化ができるようになった

残った課題

  • 大量のマージ地獄
  • ビルド職人の属人化(ビルド実行を押すだけなのに、押せるのが自分だけ…)

Githubkaigi.orgに参加

  • プルリクエストの凄さを知る
  • hubotによるChatOpsを知る

Pull Requestのお作法

  • 空コミットしてWork in Progress
  • マージできる状態でぷる陸を送る
  • マージ前にコードレビュー
  • マージしたらそのブランチを消す

ChatOps

  • コミュニケーションツールにHubotを利用する

Privateにするために

  • GitBucketの導入
  • kandan(-2015/06)
  • lets-chat(2015/07-)

現在

  • サーバーは多くなった
  • ただ、チャットを通して誰でもDeployできるようになった

TIMTOWTDI

  • There Is More Than One Way To Do It
  • どんなツールがあっても良い

BSCINABTE

  • 時には共通することも悪いことではない

まとめ

  • 解決したいものを定義した上で挑戦すると失敗しにくい
  • やってみないとわからないことが多いので、まずやってみる
  • 正しいと思う、ワクワクするかどうかも重要

感想

  • 「事前のアンケートでは人気がなかった」と言っていましたが、私は一番聞きたかったセッションでした
  • 聞いた結果も大満足でした
  • 今、自分のところで置かれている状況は似ているので、参考にしたいと思います

JTF2015講演まとめ

nihonbuson.hatenadiary.jp

「インフラエンジニアがUnityをやるべき、たった一つの理由」参加レポート #jtf2015

スライド

www.slideshare.net

自己紹介

質問

  • この画像(外国人が喜んでいる写真)のネットワークエンジニアたちは一体何に喜んでいるのか?

答え

  • Pingが通った!
  • 脳内では壮大なことがイメージ出来ている
  • しかし現実の画面ではpingが通ったコンソール画面があるだけ

この喜びをデモしたい!

  • 3Dで見せよう!
  • Unityを使えばいい!

Unityとは

弊社のお仕事

  • データセンターの仮想化を真面目に目指している会社
    • それ以外は真面目じゃない
  • クラウド基盤ソフトウェア
  • 仮想ネットワーク技術

仮想ネットワークのデモを見せてよ!

  • 相手に「ネットワークが繋がった」とPingの画面を見せると、表情が暗くなる
    • コンソール画面を見せても、どれだけ素晴らしいことか伝わりづらい
  • くやしいから作ったよ!

豪華なpingアーキテクチャ

  • Packet Capture→イベント配布用TCP Server
  • 送られてきたらUnityの画面で表示

デモ

  • Packet Chapture及びイベント配布TCP ServerはRubyで書ける
  • ビジュアライズ部分はどう作るのか
    • 3Dでデザインする(Blenderを利用)
    • 木構造で対象オブジェクトの繋がりで表示
    • スクリプトを書いて、カメラオブジェクトにくっつける

一番大切な実際の反応

  • 「おおおおおおおおお…」と言ってもらえた

まとめ

  • インフラエンジニアは動いて当たり前のものを扱う悲しい生命体
  • デモは派手に楽しく

感想

  • 実にバカらしいデモでした!(すごい良い意味で)
    • 今回のJTF2015の中で一番楽しめた発表でした
  • これを見せればエンジニア以外にも凄さを分かってもらえる
  • けど、そこまで作るのが大変そう…w

JTF2015講演まとめ

nihonbuson.hatenadiary.jp

「最前線で戦う若手インフラエンジニアたちが語る『技術トレンド』と『数年後の未来』」参加レポート #jtf2015

自己紹介

モデレータ

  • @deeeet

登壇者

  • @catatsuy
  • @okkun
  • @y_uuk1
  • @rrreeeyyy

wakateinfra

  • 新卒入社3年以内のインフラエンジニアで集まったコミュニティ

今回のセッションの目標・ゴール

  • 若者は今のインフラ界隈をどう思っているのか

質問について

  • #wakateinfraのツイートを拾います

agenda

  • 自己紹介
  • 技術トレンドについて
  • 技術習得について
  • 今後のキャリアについて
  • まとめ

技術トレンドについて

  • Infrastructure as Code
    • JTFで長らく語られてきたテーマ
    • 息を吐くようにコードを書いてきた世代
    • プロビジョニングツールの良い所、悪いところ
  • コンテナ

事前アンケートより

  • Chefかpuppetを使っている
  • とりあえずAnsibleを触っている
  • Itamaeも触り始めている

@rrreeeyyy

  • 構築を担当する人によって違う
  • 全社的にはChef
    • サーバー内部の情報を撮って監視設定するため、一番柔軟性をするのでChefを使う
    • 簡単にパッケージを入れる場合はItamaeなども

@okkun

  • puppetは2006年ぐらいから使っているので、資産がある
  • Itamaeは今年の新卒のWEBオペレーション研修で使っている
    • 構成管理ツールを触るときに、Chefやpuppetは学習コストが高い*1
    • ツールそのものを学ぶ以上に、構成管理についての理解を深めてほしい*2
  • Ansibleは試してみたぐらい

Chefの学習コストが高いからAnsibleへ移行しようはナンセンスでは?

@rrreeeyyy

  • 置かれている環境の違い。複雑な環境を扱っている場合はChefの方が良い
  • 段階を踏んで、Itamae→Chefはあり
  • 2台しかない環境でChefを使うのはナンセンス

@y_uuk1

  • ツール動向よりもプロビジョニングをシンプルにAnsibleを選んだが、RubyだしChefを選ぶ

@okkun

  • ひと通り調べてみたが、Itamaeは学習コストが確かに低い
  • puppet,Chef,Ansibleの学習コストはあまり変わらない
  • サーバー構成の複雑性の違いであって、ツールの違いではないのでは?

Chefは少人数を触っている間は良いが、(クックブックは綺麗に保てる)大人数になってくるとプルリクがいっぱい増えて汚くなるのでは?

@y_uuk1

  • 大人数になってもまだ汚くなってない
  • チェックできるようにできるといいな
  • 文法のチェックなどができればChefがもっと使えるかも*3

@catatsuy

  • pixivはシェルスクリプトがほとんど。それをServerspecなどで保証している
  • Ansibleは少しだけ使っている

コンテナの話

  • Dockerの話題が出てきた
  • runC and Open Container Project
  • kubernetes v1.0 and Cloud Native Computing Foundation

質問

  • Dockerを使っていますか?
  • 使ってみてどうだった?
  • 2年ぐらい経ったらどうなっていると思う?

@y_uuk1

  • 使っている。本番では使っていなくて、パッケージ用ビルド、CIの環境、ステージング環境で使う
  • インフラエンジニアよりもアプリケーションエンジニアで使っている

@catatsuy

  • 本番で導入している。
  • CoreOSの上で動いている
  • アプリケーションはScalaで書かれているが、そのVersion管理で役立っている
  • pixiv本体では難しいかも
  • ネットワーク周りのパケット変換やDeploy周りがまだまだ
    • pixivはIPが変わらない前提でDeployしている

@y_uuk1

  • メリットはどうかな?という印象
  • Dockerを使うメリットを明確化してから動いたほうが良い
  • Versionの統一化のメリットを出したい
  • Jenkinsで使うと途中でいいやと思って止めると、プロセスが動き続けていて問題が
  • 細かいところで躓く
  • Imageにしてそのまま本番に持っていく思想は良いと思うが、それなら別のものでも良いかも

@catatsuy

  • pixivについては問題が起きていないが、chrootで十分なぐらいかもしれないから、Dockerを使うべきかはもう一度考える必要がある

技術習得について

  • どうやって最新情報をキャッチアップしているのか
  • どうやって学んでいる?
    • 触ってみる
    • ソースが公開されていれば読む
    • 本を読む

おすすめのサイト

@y_uuk1

@okkun

@catatsuy

@rrreeeyyy

@deeeet

最近読んだおすすめの書籍

@y_uuki

@hfm

@rrreeeyyy

@deeeet

今後のキャリアについて

  • 今後どういう仕事をしてみたい?
  • 今後どのようなことに挑戦してみたいか?

@y_uuk1

  • 長期で運用サービスことが多いので、一から構築していきたい

@catatsuy

  • もともと開発に入ってインフラに異動したので、将来的にはインフラの知識を持ったアプリケーションの開発をしたい
  • 教育系の方向には今は予定していない

@rrreeeyyy

  • 運用を消したい。構築は省力化できていたが、運用はまだまだ省力化できていない
  • 分散システム、モニタリングなどをどんどんやっていきたい

@deeeet

  • 運用が辛いので、運用を無くしていきたい
  • ツールはどんどん出てきている(ConsulとかHashiCorpとか)

@okkun

  • 入社当時は別の事を知りたかった
  • 新卒研修をやってみて、若手の学習する組織づくりをしていきたいと思うようになった
  • 自分達が進んで学んでいく環境を作っていきたい
  • 研修と教育は別
  • 教育を会社でやろうとすると、業務知識を詰め込むことになりがち
  • 教育を受けた側がどう感じたのか、どうレベルアップしたのか言及していないことが多い
  • 日本で教育というと詰め込み方が多い
  • 自分達が進んで興味を持ってもらえるようにしたい
  • 詰め込みたくない
  • 10月まで研修中。それまでのやった内容はブログで公開中 blog.hifumi.info

質問

Q. 同僚と意識を高め合うためにはどのようにすれば良いか?

@okkun

  • ペパボはサービスごとにチームがあるが、インフラだけは横串を透している
  • 取り組みとしては、インフラチームで集まる会をしている(ポヨン会)
  • 高め合うには、酒を飲むとか
  • あとはSlackで話すとか
  • 社内用のSNSでみんなのブログを紹介するとか

@y_uuk1

  • 高め合うことを考えたことがない
  • はてなの人はみんな優秀だから
  • 高まる人を採用しましょう
  • モチベーションを上げる仕組みもある
  • 会社のブログで100user以上取れると寿司が食べれるとか

感想

  • このツールがベストプラクティスという確固たるものがあるわけではなく、現在のビジネスに合わせて利用している印象を受けました
  • やっぱりはてブが良いんだね
  • 質問の内容を聞いている時、「登壇しているところの会社は人事・採用時点で切り捨てるんだろうなぁ」とすぐに思ったが、それをオブラートに包んで答えていたように感じました

JTF2015講演まとめ

nihonbuson.hatenadiary.jp

*1:教育コストと記載していましたが、訂正しました。ご指摘いただきありがとうございました!

*2:ご指摘があり、訂正しました。指摘していただきありがとうございました!

*3:発言者を間違えていたため修正しました。ご指摘いただきありがとうございました!