はてな・ペパボ技術大会〜インフラ技術基盤〜@京都 7/2

はてな・ペパボ技術大会〜インフラ技術基盤〜@京都 - connpass

行ってきました．メモってたのでせっかくなので共有しておきます． gistでいいかとおもったけどスライド埋め込みとか考えたらブログに雑に投げたほうが見なおしやすそうと思ったのでブログで． 自分で発表したわけでもないし，感想とか書いてるわけでもないけどまぁいいかってカンジ．

注意

わかってない人が書いたメモなのでいろいろわかってないメモが書かれてます． 理解度に関係なく聞き漏らしたところ雑に書いたりしてるので発表様がおっしゃってた話とちがうところもあるかもしれない． 特に座談会の内容とかは Twitterのハッシュタグみてたら @matsumotory さんと @yumu19 さんがまとめてたのでそっち見たほうがわかりやすいかも．

Togetter

http://togetter.com/li/994969

ということで雑にtogetterつくっておきました．#pepabohatena で検索したやつからスパム2-3個消しただけです． そういえばtogetterだめな人とかいるかもじゃん…!ということに気づいたんですが全員に連絡するの流石につらいのでダメなひと @haya14busa まで連絡していただければ幸いです．勝手に使って申し訳ないでした :bow:

記事書いてる間に @yumu19 さんが作ってた -> はてな・ペパボ技術大会〜インフラ技術基盤〜@京都 #pepabohatena ツイートまとめ - Togetterまとめ

タイムテーブル

time	名前	タイトル	時間
13:30		受付開始・開場	30分
14:00	y_uuki(はてな)	開会宣言・会場説明	5分
14:05	y_uuki(はてな)	はてなにおけるLinuxネットワークスタックの性能改善	25分
14:30	matsumotory(ペパボ)	Webサービス基盤の自律制御と動的平衡性	25分
14:55		休憩	5分
15:00	ichirin2501(はてな)	計算量と僕とWeb開発	25分
15:25	pyama(ペパボ)	STNS 〜点と線を結び新しい何かを作るコト〜	25分
15:50		休憩	5分
15:55	masayoshi(はてな)	負荷分散技術を選ぶ時に考えること	25分
16:20	monochromegane(ペパボ)	サービスに寄り添うログ基盤 - ログ収集のその先に -	25分
16:45		休憩	10分
16:55	masayoshi(はてな) taketo957(はてな) alotofwe(ペパボ) hanazuki(ペパボ) モデレータ stanaka(はてな)	若手インフラ座談会	40分
17:35		懇親会 軽食と飲み物を用意しています！
19:00		お開き

開会宣言・会場説明

14:00 | y_uuki(はてな) | 開会宣言・会場説明 | 5分

• 発表6本+座談会
• アンケート

はてなにおけるLinuxネットワークスタックの性能改善

14:05 | y_uuki(はてな) | はてなにおけるLinuxネットワークスタックの性能改善 | 25分

はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena // Speaker Deck

• はてなのウェブオペレーションエンジニア．新卒1年目の仕事
• 今は3年目
• 3層構成 LB <-> proxy <-> application <-> database
• ボトルネックどこ?
  • CPU: %user/%sys/%iowait
  • Mem: used/cached/buffer
  • Disk: read/write
  • NW: tx/rx/tx
• ソフト割り込み(パケット受信)の負荷が高いときの話 (%soft)
• ネットワークスタック
  • ネットワークi/oを実現するために必要な要素群．低レイヤより
    • NIC/パケット送受信/etc…
• ネットワークI/O 高速化
• パケット受信フロー NIC -> Kernel -> Process
  • この辺の話かな? 8.3. パケット受信の概要
  • 
  • NIC: 物理デバイス
  • ネットワークカード - Wikipedia
  • NIC ->(ハード割り込み) -> パケット受信 -> プロトコル処理 -> データ受信処理 -> Process
  • 割り込み2種類ある．なぜか?
  • ハード割り込みだけだとパケット受信のたびにプロトコル処理まで実行しちゃう
  • なので一旦バッファにいれる．ソフト割り込み
• NAPI (New API)
  • 1パケットずつでなく複数パケットごとに割り込み
  • ポーリングによってとってくる．待ち時間発生するので負荷が高い時だけやるみたいに賢くなってる
  • ソフト割り込みを減らす
• HAProxy の台数増問題 (実際に取り組んだやつ)
• 割り込みが多い -> 割り込み減らしたい
• HAProxy のネットワーク負荷が高いのでHAProxyを DNS RR で並べた
• Interrupt Coalescing
  • ハード割り込みを減らす
• NICドライバのパラメータ検証した
• RPS (Receive Packet Steering)
  • コア間割り込み
• RPS でRedisチューニング
  • Redisは1スレッド
  • カーネルのネットワークI/O処理するスレッドと Redisのスレッドは分散可能
  • -> CPU% 10% 減 (コンテキストスイッチが減ったり，キャッシュが効くようになったからっぽい)
  • redisの公式ページにやりかた書いてある http://redis.io/topics/benchmarks
• ユーザランドへゼロコピー
  • そもそもカーネルに処理しないという変態処理．
  • パケットを NIC -> ユーザランドへバイパス
  • 実装: netmap
  • まだ実用ではなさそうだけど研究されてる
  • ソケットAPIの限界
    • ソケットAPIではゼロコピーできない
• まとめ
  • OSの内部面白い．OS内部の技術の外出し
  • ソフト割り込みにより遅延処理
  • ジョブキューのような非同期処理
  • 割り込みとポーリング
  • OSの技術をもうちょっと上のレイヤの技術に応用してやったりするのベンリ

Webサービス基盤の自律制御と動的平衡性

14:30 | matsumotory(ペパボ) | Webサービス基盤の自律制御と動的平衡性 | 25分

• @matsumotory 松本亮介の研究・開発業績ページ by matsumoto-r
• 技術基盤チームで研究開発してる
• 目次
  • なめらかなシステム
  • Webサービスの現状・課題
  • 自立制御
  • 動的平衡性
• なめらかなシステム
  • システムにとってのユーザ，システムを構成するサーバ等の要素のカテゴリや特徴を詳細に認識する
  • 人間の労苦は避けたい
• Webサービスの現状・課題
  • bad UI / 遅い / etc… -> 快適に利用できるのが当たり前
  • サーバの運用大変
    • 高負荷・障害対応
    • 問い合わせ
    • バジョンアップ
    • 監視
    • 新規構築
• 監視に注目してみる
  • 閾値設定はムズカシイ
  • 1時的な高負荷は無視したい．すぐもどるならok
  • 傾向が変わるならすぐ知りたい
  • 正常にみえるけど異常っぽいものを検知したい
  • 段階的な傾向の変化を検知したい．階段みたいな．でも1時的なものは無視
• 詳細な変化と原因を知るには人の目が必要．でも自動で制御したい
  • 人は何をみてるか? 対象の振る舞いをみてる
  • 振る舞いを表す特徴が知りたい!
  • 人工知能でやれるか
• 考え方
  • 特徴がある
  • 通常の状態を学習
  • 外れた状態を解析
  • 連速的に外れた状態が異常のはじまり
• 各種基盤技術
  • [x] 設定をプログラム化
  • [x] リソース制御連携
  • [ ] 特徴量定義と解析 <- ここ
• 特徴量解析
  • 変化点検出やクラスタリングなど研究はされている
  • mruby-changefinder matsumoto-r/mruby-changefinder: ChangeFinder class detect change points via continuous outlier and smoothing.
  • 複数データの関係性を得る
• Webサーバの自律制御
  • 特徴量抽出による検知できる点の増加
  • 閾値以下でも傾向変化の細かい検知ができる
• 細かい傾向変化した時点でどうするか?
  • 異常検知．誤検知もある．false positive/negative?
  • すぐ制限とかは影響でかい
  • なんかアクションはとりたい
  • システムとしてバランスを取りたい条件ある
    • マルチテナント環境とする．
    • リソースが逼迫してきたのみ制限かけたい．自動で制限したい．
    • グラフなめらかにしたい．
  • e.g.
    • どのホストが変化点スコアが高い?
    • 重み付け (優先順位つける) example.com:95, matsumoto-r.jp:93, …
    • 傾向変化ごとに重みつけリスト更新
    • 全リソースが逼迫 -> リストを元に自動制御
    • 逼迫してないなら重みつけリストをつくるところだけしとく
  • 時系列データの生成
    • 相関関係の時系列データも作れる
    • 全体の負荷とホストの負荷どっちか
• 要素技術
  • 機能拡張 mod_mruby
  • mruby-resource
  • mruby-changefineder
  • etc…
• 制限の実装方法
  • リクエスト単位でCPU/IOなどの割当を変更
  • cgroup/rlimit
  • e.g. 特定のcgroupにリクエストをアタッチしてCPUを20%に制限する．レスポンス返したらデタッチ
• ミドルウェアが特徴量抽出解析・制限行いたい
• webサービスの動的平衡性
  • 生命とは? 動的平衡にある流れ

  • 動的平衡（どうてきへいこう、英語：dynamic equilibrium）とは、物理学・化学などにおいて、互いに逆向きの過程が同じ速度で進行することにより、系全体としては時間変化せず平衡に達している状態を言う。 – 動的平衡 - Wikipedia

  • 細胞周期チェックポイント - Wikipedia
    • 細胞: さーば
    • 動的平衡: サーバの構築と破壊
    • Web サービス基盤を生命のように扱う
      • 異常・エントロピー増大からは逃れられない
      • 自分で自らを破壊・増殖・再構築していく
      • 一つ一つの細胞の調子わるいな?とかは僕らだってみてない．1部変でも全体としては大丈夫．
    • 詳しくは: なめらかなシステムのアイデアと設計概要 / namerakad-idea-design // Speaker Deck
• 今後: STNS/haconiwa, …
• Q&A:
  • フォールトトレランスとの違い?
    • 現時点はそこまで．循環するパターン．状態を持つサーバと持たないサーバがある．この辺とかの落とし所を考えてる
  • from yuuki: Docckerとかで動的にスケールしてるけど，違うアプローチっぽい．どう違う? キューバネティスとか?
    • こちらはサーバを積極的に，自主的に落として循環していくといった部分が違う．元気なサーバでも任意の時間経過で落としたり．
  • from astj: バースト．イベントやyahoo砲とかのバズり，が怖い．これを異常検知するのはむずくてなかなか考えても答えが出ない．自律制御のスピード超えてバースト来たらどうする?
    • 全体的にはバーストに対応したい．落とす条件．3時間で落ちそうなやつが1.5時間で落ちたなら1つではく2つのVMを再構築するといった方法あるかも．落としたときに条件によって10倍再構築するとか．

netflix とかも似たようなことやってる感じらしい?

mackerel で出来たりしたら最高だな〜と思った．

なめらかなシステムのシミュレーションはこれを見るとわかりやすいです https://t.co/PK3jn4cJvi #pepabohatena

— 松本 亮介 / まつもとりー (@matsumotory) July 2, 2016

計算量と僕とWeb開発

15:00 | ichirin2501(はてな) | 計算量と僕とWeb開発 | 25分

• @ichirin2501 いちりんちゃんさん
  • アプリケーションエンジニア2年 ->(転職) web オペレーションエンジニア1年(hatena)
  • スピリチュアルな発表!
• もくじ
  • 計算量について
  • mysql クエリ改善
• 計算量とは?
  • 大変さの指標．
  • 係数無視 O(3n³) -> O(n³)
  • でかいやつだけ O(n³ + n²) -> O(n³)
• 計算量といちりんちゃん
  • 競プロで向き合う．
  • 計算量と時間の基準・感覚がある
  • O(10⁷) ~ O(10⁹) 0 -> 1s くらいじゃん?みたいな感じ
  • データサイズからの見積もり
    • 1sec デッドラインの見積もりならこんな感じやろ的な．
    • n <= 10⁶ -> O(n)
    • n <= 10⁵ -> O(nlogn)
    • n <= 3000 -> O(n²)
    • n <= 100 -> O(n³)
    • n <= 20 -> O(2ⁿ)
• MySQL 改善のはなし
  • group by / distinct の迷い．どっちでも重複除外できるので実現可．
    • follow/followerテーブル的なものを想定
    • friend_id 重複なしで 1000件ほしい
    • 結果を言うと group by だと遅いケースがあった
    • group_by で OR句のuser_idが多いと異常におそくなった
    • どう計算してるか知ればいいじゃん
  • インデックス構造
    • インデックス B+tree
    • 主キーのインデックス clustered index
    • 主キー以外のインデックス secondary index (主キーがこれでわかる)
    • B+tree はleafが連結リスト．rangeで検索とかのときにベンリ
    • 例とか．この辺発表の図をみるとわかりやすくてベンリ
  • 話をもどしてfriend_id. なぜ遅いのか?
    • オーダーが違うかも
    • 意図してないインデックスで検索してるかも -> オーダー線形なってるかも
  • 結論そうだった
    • explainするとわかる
    • オプティマイザが間違った判断してた(あるある．経験則). distinct だと解決した
    • 経験則やexplain使わなくても計算量と時間の感覚でどこがまずそうかわかることもあるよ!
      • ミドルウェアのどのへんが悪いかとか計算量の感覚やインデックスの使われ方を理解して推測したり出来るとベンリ
• Redis の話
  • redis とか
    • kvs nosql(ほかにもグラフデータベースとかあるよねー)
    • list/set/sorted sets(rankingの実装らくとか)/etc .. データ構造いっぱいあってベンリ
    • メモリ最適化 2.2 から入ってる．勝手に圧縮してもらえる
      • -> パラメータ眺めてオーダーとか変わったりするのでは?と推測
  • 怪しいのでパラメータ変えて実際試す
    • データ数と実行時間からオーダーわかる
    • データ数10kで1 sec超えるのオカシイのではと気づく．
  • やっぱり -> データ構造違ってた
    • ドキュメントに実は書かれてたりも．
• まとめ
  • 知識だけじゃなく感覚を身に着けてるとすぐわかったりしてベンリ．現場で検証しまくるとかできなかたったりするし．
  • まつもとりーさんも言ってたが快適にウェブサービス使えるのは当たり前だし，この辺にコミットするために計算量ベンリ
• Q&A
  • from yuuki: このへんミスったりすると自律制御したりしても一瞬でリソース食いつぶしたりするし，このへん自律制御するのどうするかとかもおもしろそう

べんり ホーム - 鳥獣戯画制作キット

計算量の感覚大事．

STNS 〜点と線を結び新しい何かを作るコト〜

15:25 | pyama(ペパボ) | STNS 〜点と線を結び新しい何かを作るコト〜 | 25分

• やましたさん． @pyama86
  • ムームードメインやってる
• Linux のユーザ管理
  • いつから LDAP 主流だと錯覚してい(ry
• 最近のユーザ管理
  • root おおい．
• rootは問題あるよね
  • セキュリティ事故の追跡
  • sudo権限の分離
  • userの追加削除管理困難．追加でポリシーのため他のサーバにも足す…とかやるとこまる．
  • rootはアブナイ!!!
• でもなぜやってしまうか
  • なにかあったときしか困らない
  • まぁLDAP構築たいへんだよねとかある．
• STNS で解決!
  • STNS/STNS: Simple Toml Name Service
  • 名前解決/公開鍵取得/アカウント認証のみを提供．LDAPはいろいろできすぎて困る．
  • ls -ltr の名前は実はid. pyama -> id:1000 ．これが名前解決
• デプロイユーザの管理できる
  • capistorano とか公開鍵たしてsshでやるよね．authorized_keys 管理だるくなるよね．
  • stnsだとスッキリ!誰がdeployできるか一目瞭然でよい．
• 組織構造を表現できる
  • group
• シュッとインストールできるよ! 2.5min
• 事例
  • pepaboさん事例．ユーザ管理もgithub flowで. ghe でpr -> droneでテスト & レビュー -> deploy
  • 承認してマネージャーが承認して…とかめんどくてそれ解決できてベンリ．エンジニアで管理
  • ghe で全部管理できるので入退社管理とかも楽
• プロダクトを運用すること
  • ヒントとなった技術からアイデア得たり
  • mackerelのtomlとかgo使ってるやつ参考にしたり
  • linuxで利用可能な共通ライブラリがgo1.5から作れるようになってこれがでかい．Cを書かなくてもLinuxのシステムに手を入れられる
  • 自分が開発者だし自分がSTNSを最高にできる!!!

LDAP とかユーザ管理あんまり関わってないけど便利そうだった．良い話きけて良い．

• Q&A:
  • from yuuki: hatena は LDAP だけどSTNSよさそう!

負荷分散技術を選ぶ時に考えること

15:55 | masayoshi(はてな) | 負荷分散技術を選ぶ時に考えること | 25分

負荷分散技術を選ぶときに考えること // Speaker Deck

• masayoshi @yoyogidesaiz
  • 新卒．めでたい．
  • SDN(Software-Defined Networking) 大学でやってた SDNとは｜Software-Defined Networking - 意味/定義 ： IT用語辞典
• 負荷分散技術の概要
  • データセンター分散したり
  • ロードバランサーでbackend web分散したり
  • サーバ内/ロールごと/サーバごと のだいたい3つの分散ある
• サーバ内リソースの負荷分散
  • ハードウェア機能: hyper-threading, raid0
  • ハードウェア意識のOSの負荷分散: numa, rss/rfs/rps
  • OS意識のアプリケーションの作り方: fork()/clone() などのシステムコール
  • Numa NUMA - Wikipedia

    • NUMA（Non-Uniform Memory Access、ヌマ）とは、共有メモリ型マルチプロセッサコンピュータシステムのアーキテクチャのひとつで、複数プロセッサが共有するメインメモリへのアクセスコストが、メモリ領域とプロセッサに依存して均一でないアーキテクチャである – NUMA - Wikipedia

  • application
    • fork() プロセス
    • clone() スレッド
    • select() プロセス <- x (io多重化とかに影響するだけでCPUには影響しない?)
    • このへんいろいろ理解してアプリケーションコードかく! (なるほど)
• ロールごとの分散
  • proxy/web/db などのロールの分散
  • proxyでキャッシュしたり，全部のリクエストがdbまで到達しないようにとか
  • キャッシュ
    • ユーザに近いところで返す
    • キャッシュヒットしなくて破綻とか実装に無理があったりとかもする．
    • -> 使いどころを見極める．キャッシュは麻薬
• サーバごとの負荷分散
  • この辺がインフラエンジニアに特にやりがいあったり
  • 拠点ごとに分散．
  • load balancerでパケットを分散
  • 負荷分散技術を実現するために分散システムの考え方を参考にしたり
  • 透過性: 透過性 (情報工学) - Wikipedia)
  • DNSラウンドロビン
    • 位置透過性を実現
  • ロードバランサ
    • 位置透過性実現
    • ヘルスチェックできる
    • でもネットワークの制限受けたり
  • Proxy
    • haproxy/nginxなど
    • ヘルスチェックできるし位置透過性も高い
  • 分散先ノードのヘルスチェック
    • 監視: how?
    • 異常(どんな?)のあるノードを削除
  • ヘルスチェックむずい．
    • OK返してるの本当ok? 中身見たら実はngとか
    • ビザンチン将軍問題．ビザンチン将軍問題 - Wikipedia
    • Gossip protocol ゴシッププロトコルによる冗長化と負荷分散の検証
    • 分散型コンセンサス・アルゴリズム プロトコル まとめ - Qiita
  • ロードバランサの耐障害性
    • 冗長化技術であって負荷分散技術ではない
• まとめ
  • 負荷分散の仕方まとめ
  • 必要以上に複雑にしない．コスト増とかもある．simple is best
  • 本当に必要なのか最高する
  • オープンソースカンファレンスはてなでブースだす． オープンソースカンファレンス2016 Kyoto - オープンソースの文化祭！
• Q&A
  • どこが負荷おおいか?
    • disk がおおい．dbとか．ロールごとに分けておいてキャッシュ聞かせていく戦略おおい．(計算機の仕組み的にdiskがおそい from yuuki)．最近iodriveとかあって速くなってきてるのでスケールアップが多い．

サービスに寄り添うログ基盤 - ログ収集のその先に -

16:20 | monochromegane(ペパボ) | サービスに寄り添うログ基盤 - ログ収集のその先に - | 25分

サービスに寄り添うログ基盤/pepabo_log_infrastructure_bigfoot // Speaker Deck

• monochromegane
  • minne
  • 普段 rails 書いてる．最近ログ基盤の開発してる．
• ログはいいぞ!
  • ログはウェブサービスにおいて重要
• 行動ログ
  • アプリケーション層で出力するログ(apacheのログとかではない)
  • いつ，だれが，なにをやったか特定できる
  • 最終結果だけでなく，どこであきらめたか．どう迷ったかが分かる

    • 特にどこであきらめたか．どう迷ったかが分かるところにサービス改善のヒントが詰まってる!!!

• 行動ログ活用段階
  • 収集: とりあとめる
  • 分析: 視覚化したり分析
  • 活用: 分析結果を使って継続的なサービス改善
  • “ログの活用”
    • ログがたまるだけとか，グラフでてバンザイ！するだけではだめ!!
  • -> ログの活用基盤をつくる!
• Bigfoot
  • ペパボの次世代ログ活用基盤
  • minnneのそれでもある．
  • UID 振る．アプリでログを吐いて集約基盤へ -> 分析 -> サービス改善など活用
• Bigfoot を支える技術
  • ログを送る
    • fluentd rack-bigfoot(rails) OSS的な感じではなさそうか…?
  • 集約基盤 Treasure Data
    • 活用に力入れたかったので集約基盤はとりあえずTDに任せた．あとで自社のものにするかも
    • Hive QL. 行動ログをSQLライクに扱える
  • ワークフロー
    • tdのスケジュールクエリを利用．これはwebのコンソールからorAPI.APIだと個々人が勝手にいろいろできたりしてこまる
    • -> クエリのコード管理にpendulum Treasure Dataのスケジュールジョブをコードで管理するPendulumというgemをつくった · THINKING MEGANE
    • コードレビューとか管理できてよい
    • digdag というtd社公式のものがあるので移行中 treasure-data/digdag: Workload Automation System
  • 属性情報
    • 行動ログのidから性別などなど属性情報を組み合わせると分析の幅が広がる
  • 名寄せ
    • サービスのアカウントと各クライアントをマッピング
    • 未ログイン状態のアカウントも名寄せ後に過去に遡って紐付け
    • cookie syncと組み合わせてサービス間の紐付け
  • Big Cube とCube
    • BigCube: 全サービスの行動ログを集約してる
    • 切り口が確定したらCubeに切り出す(cubeに切り出されるとpostgresに入るので速く集計できたりする)
  • 視覚化と分析
    • pivot tableのすごいやつ． Tableau社のTableau Desktopを使う Tableau Desktop | Tableau Software
    • データソースとしてtdつかえる
  • 活用
    • 画面デザインの変更．ステップ見直し
    • A/Bテスト
    • -> 静的なフィードバック．人が判断．固定化する．
  • 動的なフィードバックがよいのでは?
    • システムが行動ログを吐く -> 変換したものをシステムが受け取る -> 挙動を変える
    • バンディットアルゴリズム
      • いまやってみてる．
      • A/Bテストの機会損失減らしてる．
      • O’Reilly Japan - バンディットアルゴリズムによる最適化手法
      • 強欲な感じで期間内の最良の手法を探す．最大はそれにbetする(活用)が他のものにもbet(探求)．
    • リコメンド
      • matrix factorization
      • 強調フィルタリングの一種
      • tdのなんかでできるらしい?
  • browse,card abondonment
• サービスに寄り添うログ基盤
  • 単に集めるだけじゃなくて分析，活用の段階を補助する
  • 静的フィードバックから動的フィードバックへ
  • 行動ログの循環によってなめらかな世界へ．ということでログはいいぞ
• Q&A
  • Q「送る側のサービスからログ基盤への負荷の問題はどうか」A「fluentdがよく出来ているから問題ない」 https://twitter.com/matsumotory/status/749151437850980352
  • Q「fluentd自体の負荷はどうか」A「ない、今の設計規模では大丈夫」もともとfluentd自体はつかってて大丈夫ならしい
  • td負荷? ログを送りつけるぶんには負荷は気にしなくて良い．送ったあとにインデックス使わずに集計したりするとまずい．プランやすかったりすると特に．

これ、みやけさんほぼ一人でやってたからやばすごなんですよ… #pepabohatena

— 松本 亮介 / まつもとりー (@matsumotory) July 2, 2016

まじか…

活用を重要視していてよさそう．おもしろい話だった．

「ログはいいぞ」．

若手インフラ座談会

16:55 | masayoshi(はてな) taketo957(はてな) alotofwe(ペパボ) hanazuki(ペパボ) モデレータ stanaka(はてな) | 若手インフラ座談会 | 40分

• 新卒1,2年目の人達で座談会．stanakaさん仕切ってる
• 自己紹介
  • taketo957: hatena. 新卒．インフラしてる． taketo957 (@taketo957) | Twitter
  • masayoshi: hatena. 新卒．さっき発表した まさよし (@yoyogidesaiz) | Twitter
  • hanazuki: pepabo. 大学京都．インフラしてる．渋谷．去年入社 hanazuki (Kasumi Hanazuki)
  • alotofwe: pepabo. 読み方:すずぴー．ねっとではれいか??? 去年入社．競プロ学生からやってる 玲香@健康 (@alotofwe) | Twitter
• なんでインフラ?
  • masayoshi: ネットワーク系の研究してたり．かっこいいじゃん?
  • hanazuki: KMC入ってた．サーバーいじったりするの楽しかった．
  • taketo957: B3くらいでRailsやってたらブラックボックスおおくていろいろ調べてた．京都ならはてなでインフラできそうということでアルバイトしてisuconしたりなどなど．面白くてそういう形式で入社した．
  • alotofwe: 大学時代はそんなにインフラしてたわけじゃなかった．アプリは書いていたけど，やっていてアプリはもういいやという感じになった．インフラorセキュリティやろうとおもって，セキュリティ志望だけどセキュリティするためにはインフラ知らなきゃだめなので今インフラやってる
    • 1. せきゅりてぃ専門のひとpepaboにいる?
    • 1. ちょっといる．matsumotoryさんとかも?
    • はてなではセキュリティ専門はいない．みんなでやる．
• アプリとインフラの境界? たとえばDBへのクエリ，スキーマあたりの責任や分担とかどう?
  • masayoshi: 監視業務のアルバイトしてその時はじめてインフラやった．そのときはコード書いてる人はいなかった．DBの設計まではしないけど性能のチェック，クエリのパフォーマンスチェックなどはしてた．はてなでは? -> だいたい一緒．
  • taketo957: 入社以前はもっとハッキリした境界あると思ってたけど，入ってみたらアプリ側が一緒にやってくれたりとか．インフラはmiddle wareより下はだいたいみてる．
  • hanazuki: パフォーマンスチューニングとかが境界．どっちからもみる．上からみるか下からみるかって感じ．境界がハッキリはしてない．
  • alotofwe: だいたいhanazukiさんと同じ．開発のひとからpull-reqが飛んできてレビューするとかまであるくらい境界は曖昧．ある程度権限はあるけどソレ以外はほとんど境界はない．
• インフラエンジニアになって1-2年，おもしろかったことや印象的なエピソードとかある?
  • masayoshi: はてなはオンプレ環境ある．ネットワーク機器をみてエラーパケットとかみたりした．そこで傾向とかがみれて面白い
  • hanazuki: プライベートクラウド使ってる．チョット前まではオンプレ．仮想環境を使う側．awsを使うのとは違ってどう動かすかとかツールとか作っていく．この辺が楽しい
  • taketo957: いろいろわかってきて嬉しい!
  • alotofwe: 推理小説がスキ．障害の何が原因か調べるのが探偵の推理っぽくて楽しい．
• 研修でよかったこと
  • taketo957: 今年からインフラでも新卒研修．知識編と設計編．設計編がおもしろかった．実際に動いてるサービスにたいしてこのくらいのリクエストならどう設計するか．身になる部分でよかった．
  • hanazuki: 1ヶ月間くらい研修ある．内容自体はだいたい知ってたりもしたけど試行錯誤がおもしろかった．
  • alotofwe: 今年は研修作る側．内容: railsつくって運用基盤つくってmobileつくる．最低限の生き延びるための知識を得るようなもの．インフラのものはあまり知らなかったので特に勉強になった．
  • masayoshi: 全部taketoくんに言われた! ミドルウェアの組み合わせだけじゃなくて構築するとかコードを書いて作ってみるとどこがボトルネックになるのかとかわかったりする．作ったり構築・コード書くのも研修でやるとその辺に気づけて勉強になるのでベンリ．
• hatena は京都と東京．pepaboは福岡と東京にある．2拠点でやってることに関して感じることとか?
  • taketo957: 自分がやった話ではない．東京とのコミュニケーションコストを下げる．提示前15minのslack call雑談とかやってる．(yuukiさんが導入した)
  • masayoshi: taketoさんの続きってかんじ．今すぐ，まだまとまってないけど考えを話し合い，そういうときに音声チャットあってすぐに話せる環境があるとよい．ちょっと話したいけどいいですか?って聞いたらすぐ聞けるという環境が大事でベンリ．
  • taketo957: 補足．はてなは社内の文化的にこんなことも残すのか．というところまで残す．音声もベンリだけどチャットなどのテキストで何でも残すというところもよい．
  • hanazuki: みてるサービスが違うのでそこまでコミュニケーションをする必要はそもそもない．週1でビデオコールとかしてる．コミュニケーションとりたいけど取れないときもあるのでなんとかしたい．
  • alotofwe: slackべんり．アイコンが顔写真でよい．
  • masayoshi: アイコンもよいよね!
  • どうしても落ちがちな情報．手元で詰まってるけど大変とかいう情報とか．
• ロールモデル．将来どうなりたいとか．社内社外問わず目標としてる人とかいるか?
  • masayoshi: 具体的な人物とかはあんまりない．エンジニアとアカデミック系では本来あんまり境界はない．インフラのパフォーマンスチューニングとかは個人の技術という側面がおおいので体系化して学術分野にも広めたりアウトプットしたい．
  • taketo957: 入社したときはyuukiさんにあこがれてといった．ネットワーク周り喋ってるひとがおおい．アプリ観点から観てるひとはあんまりすくなさそう．研究室でやってきた人力でやる仕組みとか応用したりしていきたい．(クラウドソーシング?)
  • hanazuki: あんまり決まってない．人力の認知力でやったりするのはうっかりとかが発生して困るのでつらい．半分寝てても仕事できるようにしたい
  • alotofwe: よくばりさんなので側面によって尊敬してる人が異なる．つまみ食いしていきたい．食べてる最中なのであんまり決まってない．
• インフラエンジニアの醍醐味?．会社のいいところは?
  • taketo957: レイヤーが下がるにつれて相手にするものが多くなる．それにつれて自分の知識も増やす必要がある．いろんな知識を裏側まで見通してやっていったりするのは面白い．会社のよいところ．新しい技術・古い技術と幅がでていてよい．
  • masayoshi: 基盤をつくるのが面白い．大規模なものを支えるところが面白い．裏方だけど支えがないと動かない．このアラート放置していいんすか?とか聞くと先輩とかが話してくれて一緒に解決してくれたり．
  • hanazuki: インフラといってもハードウェアみたりチューニングしたりなどいろいろな分野・仕事がある．いろいろできるのよい．それぞれスキなレイヤで改善できるところとかよい．
  • alotofwe: アプリと比較．アプリ開発だと適当に書いても動いちゃう．インフラだと1行追加すると大きい影響があってじっくり考慮してかかなきゃだめだったりする．向上心強い人がおおい．よくしていきたいという気持ち．勉強しやすい会社．

僕の(雑)まとめ感想とか

インフラ系のことはほとんどできていなくて，知識も全然ないけど，どんな感じでやってるのかなぁと興味はあったので参加しました． アプリケーション書くときもインフラ意識して書くとよかったりするのでインフラエンジニアとかウェブオペレーションエンジニアみたいな職種につかなくても知っておくと便利． 実際座談会の話では，はてなさんでもペパボさんでもアプリケーションエンジニアとインフラエンジニアの仕事の境界とかは曖昧で，上から見るか下から見るかの違い程度しかないみたいな話をしてた気がする． 僕も，もっとインフラ意識しながら開発していきたいなーという気持ち高まった．

ネットワーク周りだとシステムコールとかいろいろ正直よくわからんくて前提知識僕が持ってないんだなーという話は多かったけど， わかんない話でもおもしろいなーと得られる部分あったり，割とまだ分かる話(相対的に)でも知らないことがたくさん学べたり，なるほどなーとかそうだよなーよいよい!という話ばかりで どの発表もよくて来てよかった．

運営・発表者の皆さんありがとうございました．