shnagaiの日記

主にエンジニアリング関連のトピックについて雑多に書いています

【レポート】SmartNews Tech Night Vol.2 ~クラウド事業者に就職する以外の インフラエンジニアの生きる道~

久々に面白いイベントだったので、メモを公開。

感想

メモったことそのままで長くなるので最初に感想だけ。 かなり釣り気味のタイトルでしたが、インフラエンジニアがいっぱいいて楽しいイベントでした。 トークしてた人たちが、有名とこの人達だったのでオンプレを否定するような空気は全くなかった。

印象に残ったのは下記の部分

  • インフラエンジニアという括りはもうない(得意な技術領域の異なるエンジニアがいるだけ)

  • クラウドで環境作るのは簡単だけど、中身を知らないと存在価値ない(裏がどういう仕組みかを知っているかとか中身を知っているのは強みになる)

  • 世間的にアプリエンジニア・インフラエンジニアと言われている人の日常業務を比較すると実はあまり変わらなくて得意な領域が違うだけという世界

  • インフラの仕事(サーバ構築,適切な監視,必要な検証,障害対応)は変わらないが、ツールコモディティ化(Chef,Fabricとか)により、やり方は変わっている

  • 新サービスはクラウドでの方針、オンプレで育ったサービスはノウハウ・費用をどう考えてもオンプレが優位(グリー、CA,DeNA3社とも同じ見解)只、クラウド化を検討しないわけではなく明確な優位があれば常に検討はする。

  • 監視ツールの領域はみなさんかなりSaasを使っている(規模が大きいのでオープンソースをそのまま使えず、自分達で運用するよりそのサービスに全力を使っている会社に任せる方が正しいという考え方) DataDog,pagerduty,logentriesとか

  • アラートやり取りをslackに集約(これはメール、これはチャットとかでなく全て集約すると全体見えるしスピード上がる)

  • クラウドだとまず第一にみんなAWS使ってるからやはりスタンダードなのは間違いない。(只、各社得意分野違うので、GCEとかSoftLayerとか国内クラウドも組み合わせる)

  • 事業会社のインフラと呼ばれる人達は、サービスだけでなく社内も一緒に見ているのはどこでも一緒だった!

生き残る道

  • 事業会社のインフラなら、サービス目線で何でも出来る中で特定の得意技術をもつ人としてやっていく(RPGのステータスで一つとがって他は平均的みたいのが理想)
  • ミドルの一製品を極めたかったら、mysqlAWSでRDSの人になるとかそういう道はあり
  • 既得権益を守ろうとするのではなく、世の中の変化に対応して自分達のサービスにあった形で考えや行動を変えていくのは大事
  • 覚えた技術は裏切らない

インフラ専任エンジニアが一人も居ないSmartNewsにおけるクラウド活用法

SmartNews 大平さん(この人はアプリエンジニア)

  • サイバー→LINE→smartnewsと渡り歩く

1000万ダウンロード 日米 アルゴリズムで記事の選定をしているらしい

  • なぜインフラ専任がいないのか

少人数・クラウド活用している

エンジニアの数の推移 2012 1人 2013 5人 2014 15人

大事なところにだけ集中する

  • ネイティブ、サーバアプリAPI,機会学習、データ解析
  • AWSの肩にのりサーバ運用

→サーバ、ネットワーク、データセンタの管理から開放される APIプログラマブルに管理 スタートから現在まで全てクラウド上にある

なぜフル活用出来たのか クラウドサービス向けのアーキテクトになっているから タイミング良くAWSが整ってきて料金も下がった

向かないケース

write heavyな処理 over10Gbpsトラフィック リアルタイム性 低レイヤーでカリカルのチューニングやカスタマイズが必要なもの LINEとかは向かない

仮想環境の限界はある ・ネットワーク最適化(経路とか) ・ioDrive

向くケース

ディスクアクセス少ない トラフィック少ない とか向かないケースと相反するケース

smartnewsのシステムは?

疎結合アーキテクチャ ・バックエンドは非同期多様 ・ディスクアクセス減らす為、mem多様 →永続ストレージへは遅延書き込み ・キャッシュを多様している(自作のエンジンとフレームワーク)

どのようにAWSでサーバを管理??

・provisioning tool使う

chefやfabricで誰でも透過的に使えるように 各エンジニアが一定のルールにもとづいてレシピ書く

saasを使って運用系のサーバの運用がない姿勢

saasを組み合わせて自前ではやってない DataDog 監視ツール(nagiosとか) newRelic プログラム側の pagerduty (通知系) logentries (es+kibana) chartio クラウド版のBIツール slack 監視アラートを集約 →情報の分断を防ぐために相談もアラートも全てslackに集約 →ビジネスの人も チラ見するだけで色んなチームの状況わかる →情報をAPUを使ってプロフラマブルに組み立てる

インフラエンジニアとは。。

設計・構築・運用する人

ミドルから下見る でもsクラウド出てきて、OSまではクラウド事業者がカバーしてきた

インフラとアプリのレイヤが重なってきてきた

smartnews アプリ・インフラもやってる業務は同じで、得意領域が少し違うだけ →そこには境目はない

これからのインフラエンジニアについて考えていること

グリー 梶原さん

社内インフラ・サービスインフラ共に見ている

・新サービスはAWSでやってる

グリーの事例

情報システムのインフラ

業務アプリ オンプレ ファイルストレージ クラウド・ストレージ →latencyとセキュリティの問題(機密情報どこまでおけるか)で一部オンプレ

サービスインフラ

オンプレ AWS Openstack(オンプレクラウド) ミックスで使っている

オンプレ

ほぼ物理 ラックとサーバの最適な配置は課題 複数DCで相当数サーバを管理(DR考えつつ)

OpenStack 2013

仮想化でリソースの有効活用 プライベートクラウド 本番環境・開発環境で利用 ポータル作って開発環境を楽に使えるように提供

AWS 2014〜

新規にリリースするサービスはAWS利用と決めてる

ハイブリット

DirectConnectを使って組み合わせる 保守切れのタイミングで考える 在庫を持ちたくない特殊なハード ピークとオフの差が大きいサービス

やりたい事

GCP,Softlayerを使いハイブリットクラウドに拡大 Openstackのコンテナ対応 Whiteboxスイッチ

選定基準 ・コスト 大規模調達するとまだまだ物理は安い 年に数会値下げはあるAWS

・メンテナンスのコスト サービスによってはメンテナンスの調整コストが高いものがある AWSのメンテナンスは結構あるので、それに耐えれないサービスはやらない

いいとこ

デリバリスピードはやい 不要なときにすぐすてれる

課題

ブラックボックスの為手が出せないレイヤがあり何か起きた時のインパクトが大きい

障害→サポート連絡→繰り返し、、 本質にたどり着くのに時間かかる →自分でログインしたりハードみたりというのと比較すると辛い 落ちて当然のアーキテクチャでアプリが出来てないので辛くなるとこがある(オンプレ用)

saasツールの利用も増えてきた

pagerduty datadog sumologic

これからのインフラエンジニア

サーバアプリ開発 サーバ運用 アプリ運用 ソースコードまでみてトラブルシュート DB NW DCやNWの設計

クラウド化進むとどのレイヤーも影響を受けかねない

クラウドに限った話ではないが変化を許容して柔軟に対応する事が重要

これから起きること 原因わからず負荷上がったからサーバ追加しよう

ビジネス的にはOK エンジニアリング観点はNG

何かわかんないけどioDrive入れたら早くなった

クラウドで運用は楽になるけど、これまで大変だった事がブラックボックス化され知識を得る機会がなくなってきた、 中身を知らないのは危険なことなので、競争力をつけるためにブラックボックスの中の知識をしっかりつける

要は使うのは簡単だけど、中身を知らないと存在価値ないという話

インフラエンジニアってなんでしたっけ

サイバーエージェント 桑野さん

web系インフラエンジニアの話

新サービスはほぼクラウド

でもDCがある ある程度の規模だとサーバ単価としてのコストは安い &ノウハウもある

やってること サーバ構築 適切な監視 必要な検証 障害対応 →クラウド時代になっても変わらない 只、やり方が変わっている

コード化する為のツールコモディティ化

手で自分では構築しない 基本的な部品のAPI化 スピード感ましてキャッチアップが必要

なんをするにもコード化なので、 コードを書く必要に迫られる事が多くなっている

コード化出来る土壌が整っている 仕事のやり方が変わっている

なんかが起きた時の切り分けの手段を多く持っている&出来る →これはおおきなスキルでいらなくならなくないか?

エンジニアの壁が薄くなっている 有限なパラメータをどう振り分けるか →周辺知識は伸ばしていきながら得意分野は伸ばす

サーバの負荷抑える あフォーマンス上げる 出来るだけコスト

結局は事業で御飯を食べているので、事業そのものの成長を妨げない 成長のスピードを上げる 技術を諦めることもある

インフラエンジニアという単語に悲観せずにやる 覚えた技術は裏切らない でも変化を避けることは出来ない

物理を握った人が変化を嫌い、 守りに入った時に既得権益感が出て、事業のスピードに影響 →調整・調整になりがち

コストセンターだけじゃないという事を

インフラエンジニアというくくりはもうない 得意な技術領域の異なるエンジニアがいるだけ

http://www.slideshare.net/akuwano/ss-47049999

トークセッション インフラ界のドン達に若手気鋭のエンジニアが切り込む!斬!

SmartNews 坂本さん(モデレーター) SmartNews 大平さん CyberAgent 桑野さん DeNA 小野さん GREE 梶原さん

特徴を活かしてつなぎこむ GCP,AWS,Softlayer

オンプレで育ってきたものに関してコスト逆転しないとオンプレをクラウドに移行はね。。 便利なものは使うけど、オンプレのノウハウもあるから移行コストは高いかな。

正直試算は難しい。。

サイバー 課金部分は出さないけど他はだしていけないものはない という認識

クラウド、セキュリティの壁はある。。 →今作り上げたものがあるから → 新規サービス、ゲームはAWSは共通認識でした。

監視サービスを本気でやっている人達に、片手間でやる監視ツールでは勝てないからsaasを使うのは正しい →ニッチなところにはておどかない

どこに興味を持って何をやっていきたいかを突き詰める smartnewsも社内インフラもある

SmartNewsさん素敵な面白いイベントをありがとうございました。

オフィス見学も出来たし。(ぶれぶれ。。) f:id:nagais:20150415223717j:plain f:id:nagais:20150415223452j:plain f:id:nagais:20150415223455j:plain