Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20140410_geechs_nanapi_pub.pdf
Search
wadap
April 11, 2014
Technology
13
6.1k
20140410_geechs_nanapi_pub.pdf
wadap
April 11, 2014
Tweet
Share
More Decks by wadap
See All by wadap
20200311_コネヒト_リモートワークを支える文化
wadap
2
2.5k
副業が難しいと思う理由
wadap
3
590
2016-11-10_chuo_university
wadap
2
3.8k
how_to_survive.pdf
wadap
0
100
how_to_choose_technology
wadap
7
4.2k
nanapiの会社風土と文化づくり
wadap
2
23k
20140826_nanapi_engineer_culture_pub.pdf
wadap
2
130
nanapiの開発現場をどのようにして回しているか
wadap
40
11k
nanapi TechBlog
wadap
1
6.9k
Other Decks in Technology
See All in Technology
エンジニア候補者向け資料2024.11.07.pdf
macloud
0
4.5k
ガバメントクラウド先行事業中間報告を読み解く
sugiim
1
1.9k
AI長期記憶システム構築のための LLMマルチエージェントの取り組み / Awarefy-LLM-Multi-Agent
iktakahiro
2
250
「視座」の上げ方が成人発達理論にわかりやすくまとまってた / think_ perspective_hidden_dimensions
shuzon
2
13k
Platform Engineering ことはじめ
oracle4engineer
PRO
8
650
スプリントゴールにチームの状態も設定する背景とその効果 / Team state in sprint goals why and impact
kakehashi
2
120
Fargateを使った研修の話
takesection
0
160
Product Engineer Night #6プロダクトエンジニアを育む仕組み・施策
hacomono
PRO
1
520
福岡新卒エンジニアの会
teba_eleven
1
140
TinyGoを使ったVSCode拡張機能実装
askua
2
170
【若手エンジニア応援LT会】AWS Security Hubの活用に苦労した話
kazushi_ohata
0
250
株式会社ドクターズプライム 会社紹介資料 - エンジニア向け
drsprime
0
180
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
136
6.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Docker and Python
trallard
40
3.1k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Navigating Team Friction
lara
183
14k
Producing Creativity
orderedlist
PRO
341
39k
The Art of Programming - Codeland 2020
erikaheidi
51
13k
Transcript
nanapiを支える技術 株式会社nanapi Co-Founder 取締役 執行役員 CTO 和田修一
アジェンダ ࣗݾհˍαʔϏεհ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QTͷऔΓΈ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ
アジェンダ ࣗݾհˍαʔϏεհ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QTͷऔΓΈ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ
自己紹介 • 和田修一 / @wadap • 1981年生まれ(32歳) • 株式会社nanapi Co-Founder
取締役 執行役員 CTO • インフラ〜サーバサイド開発 • emacs
略歴 • 2005年 新卒にて楽天株式会社へ入社 サーバ・インフラ系の部署に配属される • 2009年 楽天を退職し、弊社代表の古川と起業 ロケットスタートCTO(旧社名)に就任 •
2011年 社名を株式会社nanapiへ変更 株式会社nanapi 取締役 執行役員 CTOに就任
主な仕事 • テクノロジーの文化を社内に浸透させること • エンジニア・デザイナーの採用活動 • nanapiすべてのインフラ • 役員業務もろもろ
個人的にやってること 6/*9తͳΞϨ IUUQXBEBQIBUFOBCMPHDPN 6OJYͷೖߨ࠲ IUUQTDIPPKQDMBTT
ྗαʔϏε w ੜ׆ͷܙ͕ू·ΔαΠτ IUUQOBOBQJKQ w ༷ʑͳϋπʔΛఏڙ͢Δα Πτͱͯ͠ϦϦʔε w ݄̍̕ϦϦʔε w
݄ؒສ66 ݄ؒສ7JTJUPS
• 即レスQAアプリアンサー 「アンサー」で検索! • 質問してから数分以内に回答 がくるのが特徴 • 2013年12月リリース LineQとリリース被った! ྗαʔϏε
• 英語圏の人に向けた新サービ スをリリース • 4/1にリリース! ※国内へは未告知 • 英語圏を中心に展開をしてい く予定 ྗαʔϏε
• ライタープラットフォーム http://works.nanapi.jp • 記事を書いてお金を貰えるク ラウドソーシングのサービス • 2010年8月リリース ライタープラットフォーム
• 特定のジャンルに特化したメ ディアを複数作成 • 月間300万〜400万PVほど • 数十ジャンルのメディアをリ リース済み • iOSアプリやAndroidアプリで
も展開済み バーティカルメディア
• 取締役 3名 • 正社員 30名 • 従業員 75名(アルバイト含) 会社規模
アジェンダ ࣗݾհˍαʔϏεհ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QTͷऔΓΈ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ
nanapiの開発体制
現在に至るまで ʙલ ໊ ໊ ໊ ໊
໊
現在の組織体制 OBOBQJ Ξϯαʔ άϩʔόϧ &OHJOFFS &OHJOFFS &OHJOFFS Πϯϑϥσʔλղੳج൘
事業単位にアサイン • nanapiのエンジニアはただコードを書く人ではな く、サービスをつくるクリエイター • ディレクター、エンジニア、デザイナーの距離を短 くし、相互に事業を理解し高速に開発するため • 職種を超えてサービスに対するアイデアは常に活発 に議論されるようになる
職種間の情報共有 • デイリースタンドアップミーティング • 月1の社内勉強会 • 気になる情報は随時ChatworkとQiitaで共有
Chatworkでコミュニケーション
Team:Qiitaで情報共有
開発フロー
プロジェクトの進め方 • 大枠のプロジェクトの進め方は、基本的に各プロジェ クトにお任せ • 現在は、全プロジェクトがスクラム開発を実施 • タスク管理には、ホワイトボードを使ったカンバン を活用
実際に運用中のカンバン
スクラムのやり方 • 週のあたまに、対象となる期間(2週間くらい)の タスクを洗い出し、その工数を見積もる • TODO/DOING/DONE という3種類のステータス で管理をする • 毎朝の朝会で各タスクの進捗を確認する
開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞ CSBODIΛQVTI͠ɺQVMMSFRVFTU ίʔυϨϏϡʔޙɺNBTUFSNFSHF NBTUFSQVTIࣗ͠ಈUFTUࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞͢Δ QVMMSFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾDIBU௨ NFSHF࡞ۀHJUIVC্Ͱ࣮ࢪͤ
ͣʹɺ։ൃڥ্Ͱ࣮ࢪ NBTUFSQVTI͢Δ͜ͱͰ͋ͱ͢ ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞ εΫϥϜͰཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞͢Δ
開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞ CSBODIΛQVTI͠ɺQVMMSFRVFTU ίʔυϨϏϡʔޙɺNBTUFSNFSHF NBTUFSQVTIࣗ͠ಈUFTUࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞͢Δ QVMMSFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾDIBU௨ NFSHF࡞ۀHJUIVC্Ͱ࣮ࢪͤ
ͣʹɺ։ൃڥ্Ͱ࣮ࢪ NBTUFSQVTI͢Δ͜ͱͰ͋ͱ͢ ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞ εΫϥϜͰཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞͢Δ
• bugなどだけでなく、必要そう な項目はエンジニアでもどん どん追記 • チケット管理機能としては若 干シンプルだが、その分扱い やすい issuesの作成
開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞ CSBODIΛQVTI͠ɺQVMMSFRVFTU ίʔυϨϏϡʔޙɺNBTUFSNFSHF NBTUFSQVTIࣗ͠ಈUFTUࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞͢Δ QVMMSFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾDIBU௨ NFSHF࡞ۀHJUIVC্Ͱ࣮ࢪͤ
ͣʹɺ։ൃڥ্Ͱ࣮ࢪ NBTUFSQVTI͢Δ͜ͱͰ͋ͱ͢ ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞ εΫϥϜͰཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞͢Δ
開発用にbranch作成 GFBUVSFcIPUpY JTTVFTͷ*%આ໌తͳϒϥϯν໊
開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞ CSBODIΛQVTI͠ɺQVMMSFRVFTU ίʔυϨϏϡʔޙɺNBTUFSNFSHF NBTUFSQVTIࣗ͠ಈUFTUࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞͢Δ QVMMSFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾDIBU௨ NFSHF࡞ۀHJUIVC্Ͱ࣮ࢪͤ
ͣʹɺ։ൃڥ্Ͱ࣮ࢪ NBTUFSQVTI͢Δ͜ͱͰ͋ͱ͢ ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞ εΫϥϜͰཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞͢Δ
• プロジェクト単位でエンジニ アのチャットが作成されてい る • その担当プロジェクトのチャッ トルームに、PullRequestの情 報が通知でくる • この情報をベースにコードレ
ビューを実施 Pull Request
開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞ CSBODIΛQVTI͠ɺQVMMSFRVFTU ίʔυϨϏϡʔޙɺNBTUFSNFSHF NBTUFSQVTIࣗ͠ಈUFTUࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞͢Δ QVMMSFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾDIBU௨ NFSHF࡞ۀHJUIVC্Ͱ࣮ࢪͤ
ͣʹɺ։ൃڥ্Ͱ࣮ࢪ NBTUFSQVTI͢Δ͜ͱͰ͋ͱ͢ ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞ εΫϥϜͰཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞͢Δ
• コードレビューはGithub上で 行われる • PullRequestのコメントに対し て、いろいろかく • 問題なければ見たよアピール • 自動テストの結果もJenkinsが
コメントとして通知してくれ る コードレビュー
開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞ CSBODIΛQVTI͠ɺQVMMSFRVFTU ίʔυϨϏϡʔޙɺNBTUFSNFSHF NBTUFSQVTIࣗ͠ಈUFTUࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞͢Δ QVMMSFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾDIBU௨ NFSHF࡞ۀHJUIVC্Ͱ࣮ࢪͤ
ͣʹɺ։ൃڥ্Ͱ࣮ࢪ NBTUFSQVTI͢Δ͜ͱͰ͋ͱ͢ ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞ εΫϥϜͰཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞͢Δ
• Pushした通知をGithubから受 け取り、Jenkinsからテストを 実施 • テスト結果が問題なければ、 本番サーバへソースコードを Deploy • capistranoを裏側で実行
• その他Cache ClearなどのJob も搭載されている 自動test & 自動deploy
• nanapi botちゃんにツンデレ 気味に怒られる • テストが通っても、やっぱり 何故かツンデレ ※セリフを考えてるのは僕で はありません
テストがおちたら
• 新しいプロジェクトでは、CI 専用のサービスを利用 • Jenkins+テストサーバの運用 負荷は結構高い • CircleCIからTravisに移行して いく予定 •
DeployもCIツール経由で実施 自動テストにCIツールを
アジェンダ ࣗݾհˍαʔϏεհ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QTͷऔΓΈ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ
なぜChefか? • その手順書はメンテナンスされている? • 手順書通りに開発環境も本番環境もつくられてる? • 個々の開発環境を使いたいときどうするの? • 100台のサーバでも同じことできんの? etc…
• インフラにおける作業を独自 DSLで記述することができる • Rubyで直接書くことも可能 • OSの違いなども抽象化するこ とで吸収 • 同様のツールでPuppetなど
Chefを使った管理
以下のrecipeで実現 remote_file "/tmp/httpd-2.2.22.tar.gz" do source "http://ftp.meisei-u.ac.jp/httpd/httpd-2.2.22.tar.gz" owner "root" group "root"
mode "0644" end ! script "install httpd" do interpreter "bash" user "root" cwd Chef::Config[:file_cache_path] ! code <<-EOH tar xf httpd-2.2.22.tar.gz && cd httpd-2.2.22 ./configure make && make test && make install EOH end
サーバ管理方法 • すべてのサーバのセットアップ+管理は、Chefを 通じて実行する • 本番環境や開発環境を含めると、様々な環境がある がすべてChefを経由して管理 • 直接サーバに入ってのroot作業禁止!
サーバ管理のいままで ̍ʙ̑͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ ֤αʔό͝ͱʹઃఆϑΝΠϧΛผཧ ̑ʙ̍̌͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங ѱ͘ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘ͩͬͨ ̍̌ʙ̎̌͘Β͍ DIFGTPMP DBQJTUSBOPͰߏஙʴӡ༻
్த͔ΒɺLOJGFTPMP׆༻ ̎̌͘Β͍ʙ $IFG4FSWFS DBQJTUSBOPͰߏஙʴӡ༻ ։ൃڥಉҰͷDPPLCPPLͰӡ༻Մೳʹ
サーバ管理のいままで ̍ʙ̑͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ ֤αʔό͝ͱʹઃఆϑΝΠϧΛผཧ ̑ʙ̍̌͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங ѱ͘ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘ͩͬͨ ̍̌ʙ̎̌͘Β͍ DIFGTPMP DBQJTUSBOPͰߏஙʴӡ༻
్த͔ΒɺLOJGFTPMP׆༻ ̎̌͘Β͍ʙ $IFG4FSWFS DBQJTUSBOPͰߏஙʴӡ༻ ։ൃڥಉҰͷDPPLCPPLͰӡ༻Մೳʹ
• よくあるオールドスタイルな 構築方法 • 100%ミスが起きるし、何よ りもめんどくさい • wikiもあまり更新されなくな るし、作業が属人化サれてい く
手順書がんばるモデル
• 各サーバ固有情報が入る設定 ファイル配布がきつい • ApacheのIPアドレスなどがは いるときなどがある • それぞれのホストごとに設定 ファイルを管理して、svn up
• (´;ω;`)ブワッ 手順書がんばるモデル
サーバ管理のいままで ̍ʙ̑͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ ֤αʔό͝ͱʹઃఆϑΝΠϧΛผཧ ̑ʙ̍̌͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங ѱ͘ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘ͩͬͨ ̍̌ʙ̎̌͘Β͍ DIFGTPMP DBQJTUSBOPͰߏஙʴӡ༻
్த͔ΒɺLOJGFTPMP׆༻ ̎̌͘Β͍ʙ $IFG4FSWFS DBQJTUSBOPͰߏஙʴӡ༻ ։ൃڥಉҰͷDPPLCPPLͰӡ༻Մೳʹ
• 手順書うつのはだるいから、 最低限自動化したかった • 複数台のサーバを同時に構築 できるようになった! • でも、結局このcapfileの管理 が大変 •
設定ファイルの配布はあまり 解決していない capistranoがんばるモデル
サーバ管理のいままで ̍ʙ̑͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ ֤αʔό͝ͱʹઃఆϑΝΠϧΛผཧ ̑ʙ̍̌͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங ѱ͘ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘ͩͬͨ ̍̌ʙ̎̌͘Β͍ DIFGTPMP DBQJTUSBOPͰߏஙʴӡ༻
్த͔ΒɺLOJGFTPMP׆༻ ̎̌͘Β͍ʙ $IFG4FSWFS DBQJTUSBOPͰߏஙʴӡ༻ ։ൃڥಉҰͷDPPLCPPLͰӡ༻Մೳʹ
• 2012年くらいから、chefを順 次導入 • 最初は、各サーバでgit clone をしてそれぞれchef-soloを実 行していた • 途中から、knife-soloが出て
きたので乗り換え chef-soloの登場
• httpd.confなど、設定ファイ ルの中に変数を持つことがで きる • それぞれの設定ファイル内で 使用したい変数は、ホストご とに設定することが可能 chef-soloで解決したこと
サーバ管理のいままで ̍ʙ̑͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ ֤αʔό͝ͱʹઃఆϑΝΠϧΛผཧ ̑ʙ̍̌͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங ѱ͘ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘ͩͬͨ ̍̌ʙ̎̌͘Β͍ DIFGTPMP DBQJTUSBOPͰߏஙʴӡ༻
్த͔ΒɺLOJGFTPMP׆༻ ̎̌͘Β͍ʙ $IFG4FSWFS DBQJTUSBOPͰߏஙʴӡ༻ ։ൃڥಉҰͷDPPLCPPLͰӡ༻Մೳʹ
• 管理対象サーバはすべてChef Serverに登録されている • 各サーバは、1つのコマンドを 打つだけでChef Server側に定 義されているcookbookを実行 • 各サーバごとの変数も一元管
理されている Chef Serverの導入
本番サーバへの反映 $ sudo chef-client # これを全サーバで実行させる $ cap -f ./deploy.rb
chef:client # 実際はこう実行
CherServerからの反映 • Chefで管理されているサーバで自動反映させるこ とは可能だが、タイミングが指定できない分困る • そのため、設定変更を反映させるタイミングを指定 したいため、実行時だけはcapistranoで実施
開発環境への導入 • 本番環境と開発環境をできるだけ同一のものにする ため、本番環境とcookbookを同一のものを使用 • 各環境ごとによる違いは、attributesを駆使してう まく使い分ける • これにより、開発環境のupdate忘れを防げる
2種類の開発環境 • グローバルIPを持ったリモート開発環境と、 Vagrantで構築したマシン内開発環境 • 前者はChefServer経由で管理、後者はVagrant + Berkshelfで管理 • どちらもcookbookを最新にすることで、簡単に
サーバの設定を保つことができる
2種類の活用方法 • ローカルのほうが快適だけど、グローバルアクセス が必要なときもある • 社外にいるときに障害対応を行うときにあると便利 • VagrantShareとかもあるしそろそろ整理できる?
Vagrantでの開発環境の作り方 $ git clone
[email protected]
:nanapi/cookbooks.git $ cd cookbooks $ vagrant
up nanapi
Vagrantでの開発環境の アップデート $ git pull $ vagrant provision nanapi
chefの環境まとめ
• 詳しくは個人BLOGのほうに書 いたので、興味あるひとは是 非どうぞ! • さくらVPSをつかって便利な 開発環境を構築する http://goo.gl/EEcIXO • はてぶしてね!
詳しくはBlogで!
• https://github.com/wadap/ emacs-chef • chefをより快適にかくための emacsマイナーモード • まだ実装中。思い出してpush したくらいのレベル 趣味的な活動
アジェンダ ࣗݾհˍαʔϏεհ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QTͷऔΓΈ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ
• 言わずと知れた、ログコレク トツール • Webサーバに散っていたログ を、一箇所にあつめることで すごいことができる • プラグインで様々な機能拡張 が可能
fluentdを活用
Log System Overview Fluentd Cluster Web Servers raw log archive
log analyzer fluentd-plugin-mysql fluentd-plugin-s3 fluentd-plugin-td Result Output S3 + Glacier Web Servers Web Servers fluentd-plugin-elasticsearch
効果的な使い方 • アプリログの収集(エラーログ) • アクセスログの収集(エラーログ) • アクセスログのステータスの推移 • ユーザーの行動解析
• ユーザーのアクセスデータは 宝の山である • まさにビッグデータ • それを解析しやすくするため に、fluentdを活用し集約する ビッグデータの利用
• クラウド上に構築されている データ解析プラットフォーム • ログを直接送ることで、あと からSQLでデータ解析を行う ことができる • Fluentdで集約したログを簡単 に送信することができる
TreasureData
TreasureDataへの送り方 { "url" : “http:\/\/nanapi.jp”, "username" : "wadap" }
SQLで解析 $ td query -d db -w " SELECT *
FROM tbl WHERE username = 'wadap'" -o ./result.csv
• SQLの発行はWebの管理画面 からも実行可能 • 実行結果の取得は様々な取得 方法が可能 • ResultOutputという機能を使 うことで、結果をMySQLのデー タに自動INSERTさせることも
Webからも解析可能
アクセスログだけでは不十分 • ただのログ解析だけでは、いわゆるアクセス解析の 域を出ない • nanapiにおいて大事なのは、ユーザーのがどうい うコンテンツを欲しているか • そしてどういった行動をしているのかということ
3FRVFTU )551 WJB+BWBTDSJQU 'MVFOUE Overview Web Servers Web Servers Fluentd
Cluster
access_logだけではできないこと • access_logだけで取得できるログは、WebServer で取得できるデータしか出せない • アプリケーションよりのデータなどをログとしては くことは難しい • また、ログフォーマットの変更などがカジュアルに できない
実際に付与しているメタデータ • ページ属性 • ページのジャンル • 使用デバイス • リファラのホスト etc…
Log Format • データ解析を行う際に大事なのは、解析対象となる ログのデータ設計 • 取得するログは “非正規化” することが大事 •
RDBMS感覚で正規化を行いすぎるととにかく解析 しづらいデータになる
• クエリの実行パターンはある 程度限られるのでドキュメン ト化 • データ解析をエンジニアのも のだけにしないことが大事 • SQLは非エンジニアでも触れ るくらいの心意気を育てる
非エンジニアも利用
• アンサーで一部利用中 • APIのログをkibanaに流すこと でユーザーの行動解析 • バックエンドはElasticsearch • これも非エンジニアが使用 kibanaも利用中
アジェンダ ࣗݾհˍαʔϏεհ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QTͷऔΓΈ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ
これからの時代で言えること • 総合職の時代は終わった • これからは専門職の時代だ • そして、時代はこれからも変化しつづける • 変化できない人間は淘汰されていく
• これはエンジニアの仕事も同 じで、今の仕事は継続しない • 2000年前後って、HTMLかけ るだけで価値があった • いまのスキルはどこまで価値 が続くの?どこまで戦えるの •
http://logmi.jp/7770 今の仕事は10年後にあるか?
• 2009年にはスマホがここまで 普及するとは思っていない • Webはいまよりは確実に衰退 する(なくならないけど) • もっと言うと、スマホですら 今後どうなるだろうか •
大事なのは変化に耐えていく こと 求めることは変化への強さ
会社として提供できること • エンジニアは常に新しいスキルを • 非エンジニアはプログラマーレベルのスキルを • 常に新しいものをさわろう、常に最先端にいよう
• 1Qで学習するスキルを定め、 業務時間を使ってスキルを身 につける • 上記の学習も評価対象とする • これにより、サーバサイドの エンジニアも全員iOS開発がで きるように
• 次はAndroidに挑戦 実際に取り組んでいること
• Sensuという監視ツールのiOS 版クライアントをつくってみ た • これから審査だすけど、超自 信ないけど・・・ • 通ったらちゃんとアナウンス します
つくったアプリ
• 非エンジニアも技術を正しく 理解してもらうように • 週に1回、和田が直接研修を 実施 • たまに外部の人も混ぜる • 社内のレベルは高い方に合わ
せることで、全体水準をあげ る 非エンジニア向けの研修
• CTOとは、すべての技術をコ ントロールする人ではない • 「技術の正義」を浸透させ、 それを遂行させていく人 • CTOが会社の技術レベルの キャップにならないように •
http://goo.gl/38Mbk9 自分の考えるCTO像
• nanapi TechBlogで書きました • 変化に〜という点の話です • 興味ある方はぜひ読んでみて くださいね! http://goo.gl/6W2xip 詳しくはTechBlogで!
事業に人をアサインしていくのではなく 人が事業をつくっていく会社に
• Webアプリエンジニア • スマホアプリエンジニア • マークアップエンジニア • インフラエンジニア • デザイナー
• ディレクター etc… nanapiでは人材募集中
None
None