読者です 読者をやめる 読者になる 読者になる

クラウドごった煮#14 グッバイSSH

まずLT

  • 各ベンダから7分ずつ

AWSJ 荒木さん

  • 11月からADSJからAWSジャパンになりました
  • AWS、いっぱいサービスが有ります、ほとんどSSHと関係ありません
    • 関係ないサービスを選べば自ずとグッバイSSH
  • サーバレスアーキテクチャ
    • API Gateway <-> Lambda <-> DynamoDB...
    • HTTPSのみを受け付けるAPI
    • 限られた言語ランタイムのみが動く環境
    • バックエンドストレージ
  • 温故知新
    • '06 8/24、Amazon EC2発表
      • この時点では大したことなかった
    • 11/30、metadataが導入される
      • 自動化競争、no SSH競争がスタート
      • user-data
      • 有名だったのはLightscaleのLightscript
    • デプロイ自動化
      • 、に役立つサービス
      • EB, CodeDeploy, OpsWorks, CFn
        • EB登場時は「Google App Engineみたいなものです、いざとなったらSSHできます」と謳ってました
      • 組み合わせも可能
      • AWSのDockerユーザのうち相当な割合がEBのうえで動かしています
    • AWS Management Portal for vCenter
    • AWS Management Pack for Microsoft System Center
  • SSHの次はグッバイEC2を目指しています

Microsoft 久森さん

  • AzureでSSHとサヨナラする
  • SSH, Chef, Puppet, Ansible...の流れでMSが出てくるのは時代ですね
  • 結論:PaaSを使いましょう
    • →VisualStudioを使いましょう
    • 売りは一気通貫
  • IaaSなんだけど、という方
    • Azure Resource Manager
      • jsonを書いて自動デプロイ
      • CFn?
    • Azure Automation
  • 違う、そんな極論と宣伝を聞きに来たんじゃない
    • Linuxしかないし、今のサービスに適用したい

ここからが本編

  • 複雑さを減らすな、仕事を減らせ
  • 久森さん
    • 半年前にジョイン、MS初心者
  • クラウドや自動化が定時退社を与えてくれるわけではない
    • Puppet, Chefはオンプレ向けプロダクト
    • 1ノードごとに複数の役割を与えたい、それに応じてChef/Puppetは複雑なロール管理を備えた
  • クラウドは雑に、柔軟に
    • 複雑なセットアップは不要、複雑になっちゃうのはうまいこと分解できてないハズ
    • Packerを使おう
  • 結果として
    • 小難しいプロビジョニングツールクラウド時代には不要
    • 十分役割が小さければトラブルは起きにくい
    • あとはAutoScaleしときゃOK
  • 監視は?
    • 監視 as a Serviceが出てきてます
      • セットアップ時にエージェント入れとけばOK
    • MSはOMS(Operations Management Suite)というサービスが有ります

ニフティクラウド 竹内さん

さくらインターネット 横田さん

  • 横田真俊
  • 2/3くらい同業者ですよね
  • クラウド提供側の自動化

クラウド事業者にとって完全自動化は幻想

  • クラウド(利用者側)は問題なくても、クラウド基盤(提供者)では問題がたくさん
    • リソース増強
    • ホストサーバ(実機)が必要
      • もちろんリードタイム、スペック、根回しなどなどに気を使う
  • サーバ以外にも買うものがある
    • ネットワークストレージ
    • アーカイブ用ストレージ
    • NW機器
    • Windowsライセンス
  • ストレージ
    • 慎重に検証・運用しており、現状では自作ストレージとアプライアンスを組み合わせ
    • あれから実直に運用しています
    • DRBDで冗長化
  • NW機器
    • カタログスペックは幻想
    • 検証時はとりあえず溢れさせる
    • 機器をダウンさせるあらゆる方法を考える
    • メーカ・ベンダのレスポンスも重要
  • よくあるパターンはだいたい自動化出来ます
    • たとえばホストダウン
    • ストレージ障害
      • 自動的に正常なSSDに移動します
  • 我々は出来るところから運用を自動化していってます

Cloudn 鈴木さん

  • NTTコミュニケーションズ 鈴木大介
    • '11入社、Cloudn開発チーム所属
      • 電話がなる前に目が覚める生活をしていました
    • Enterprise CloudとCloudn
    • 前者はエンプラ基盤に対応、後者はAPIを整備
  • やってることはSSH
  • Fabric
    • デプロイ・システム管理ツール
    • もともとは手順書に沿って構築
      • だんだん間隔が縮んで、手っ取り早く自動化しないと...
    • 並列実行可能
    • エージェントレス
    • 学習コスト低
    • 担当者の趣味(Rubyが嫌い)
  • トラブル対応
    • 原因解析、復旧作業、影響範囲特定、ユーザ通知...
    • 影響特定・ユーザ通知の半自動化
    • CloudStack APIによる運用ポータル
      • VMの操作、VM管理、リソース管理、インシデント管理、影響特定、ユーザ通知、復旧...
      • VMが増えると標準ダッシュボードは使い物にならなくなってくるので自作
    • 通知文書の自動作成、承認は人間なので結局電話がなる
    • 解析と復旧が一番大変
  • 目指すのは完全自動化
  • Enterprise Cloud 2.0での取り組み
    • 拠点の海外展開のために自動化推進

IDCフロンティア 佐々木さん

  • 「いつもSSHしてます」みたいな話をします
  • 佐々木惇
    • 数カ月前まで構築・運用
  • 手作業の何がいけないか
    • 作業ミスのリスク
    • 知識・技術・権限が必要
    • スケールしない
      • エンジニアに負荷が集中、管理できる規模が限られる
  • CloudStackの仮想ルータ
    • 外部との接続のために必須
      • 障害=サービス断
    • 万単位で存在、勝手に増える、人手管理は不可能
    • 放置したら数時間で通信不能に鳴る場合も...
    • →監視と不具合対策を自動化
      • 定期的なヘルスチェック、自動不具合修正
    • 「自動化するしかない」ならある意味で楽
  • キャパシティ監視
    • ハイパーバイザ・ストレージなど
    • 時間がかかる
      • 間隔は日次が限界、項目数に限界、確認方法の周知が必要
    • 運用で何とかしていた
    • それはヤバイ、ということでAPIを活用して自動取得
      • CloudStack, VMware...
      • 細かい時間変化のパターンがわかる
      • 必要な項目をすぐに追加できる
      • エンジニア以外の人にも管理を依頼できる
  • 課題
    • スクリプト書ける人が少ない、ワークフローめんどいなど
  • 自動化によって大規模環境を技術・知識をあまり必要とせず

IBM Osonoiさん

  • 拡大解釈します
  • グッバイSSH
    • エンジニアの幸せのためのクラウド
    • エンジニアの幸せのための働き方
  • 小薗井康志

    • intel -> opendream -> Linux Foundation -> DELL -> 去年からIBM
    • 幸せなエンジニア人生を求め、ベンダロックインされない働き方を模索
    • OSDL Japanを設立
      • Linus主催のKernel Summitを日本で開催
      • '05年当時、MSは本当に怖かったです
    • Dell テックセンターコミュニティ
      • デルユーザ(サーバ、ストレージ、ネットワーク)のためのコミュニティ
        • 日本は会社へのロイヤリティが高い一方、人に聞けばすぐに答えが見つかることも多い
    • MeeGoユーザ会、Drupalなど
  • いくつかのポイント

    • オープンで標準的な技術をベースしましょう
      • できればOSS、トレンドをつかんでおきましょう
    • 会社の垣根を飛び越えて活動しましょう
      • 社外コミュニティ
      • 勉強会も各地であります
      • できれば国境も
    • デキる人と知り合おう
      • やっぱり勉強会、コミュニティで
  • IBMのオープン・クラウド戦略

    • Open by design
    • SoftLayerはOpenStack
      • スケジューラを独自からHeatに
    • BluemixはOpenFoundry, node.js
  • "柔らさ層"でググるとSoftlayerの本が出てきます
    • 透明性が高いです
      • HW,NWの中身が公開されている
      • 自前のPuppet,Chef,SaltStackを持ち込むユーザが多い

パネルディスカッション

  • OUT: AWS / IN: VMware
  • 内部基盤のバージョニングのロードマップなど、次何をしようとしてるのか?
  • 独自はNiftyCloud、さくら、MS、VMware
  • Softlayerはベアメタルなので仮想化レイヤからユーザに委ねられる
  • 既存
    • Cloudn: CloudStack、OpenStack
      • Enterpriseの方はOpenStack寄り
      • 個人的にはどっちに倒したい?
        • 自分が運用しているのはCloudStackだけ
    • IDCF: CloudStack
  • 独自
    • Nifty: 基盤はVMwareだが、そのAPIをバシバシ叩いてフルスクラッチでCloudStackみたいなのを作っています
    • さくら: 結構前からやってて、当時OSSが成熟してなかった 週4,5機能追加するくらいのペースになってきている
    • MS: 完全にMSテクノロジースタック、PowerShell, Hyper-V、上から下まで全部自社
      • Azureで使ってるWindows Serverはかなり魔改造されている
        • スケールするWindows Serverは2016でお手元に...
      • Azure環境でたたき台にして、一般プロダクトに降りてくるという流れ
      • NW周りは小難しい話になります
      • GPUインスタンスとか、そういう機能なかったのに魔改造しまくられてたりする
    • VMware: vCloud directorというのをプロバイダ向けに出している
      • 自分たちで使って展開している、vSphereは互換性重視で作ってます
  • クラウドを作る側?使う側?どっちに倒す?
    • →使う側の話にしましょう
    • アプリ監視を作ってる所はあんまり無いな、という印象なのですがクラウドにインテグレーションする予定は?
      • NiftyCloud: お客さんも悩んでいる、他者のクラウドの使い方わかんなくて困りました、という人も
      • AWSはCloudWatchにログ機能がついてアプリ監視と連携する姿勢
      • AzureはApplication Insightで監視する方向、個別にdatadog/NewRelicも入れれます
  • Nifty: 既存のオンプレ運用をいかにクラウドで再現するか、というとこころに苦心している人が多い
    • Time as a Service(Cron as a Service)はかなりウケました
    • 意外とNewRelicサワレナイ人が多い
  • 思ったよりオンプレ運用を再現したい人が多い
    • 学習コストは予想以上に高い
    • GCPVMあたりのスペックが低く、単一インスタンスではCPが悪かったりする
  • 要は定時退社できないから新しいことが覚えられていない、アプリが腐っていくのを見守るしか無い、という悪循環
  • みなさんのお客さんはIaaS好きな方々ですか?
  • VMwareはNWが自由にできるから入れたい、という需要が大なのではと伺ったのですが
    • NSX使ってるとL2延伸100くらい出来る
    • vSphereのHAは安定していて頼りしにている人が多い、ほかにvMotion
    • ただ、それが付加価値になっているかどうか?という話
  • Cloudn: 今あるものを動かしたい、プライベートクラウドから移行したいというケースが多い
  • SoftLayer: ほぼほぼIaaSを触りたい人、という感じ
    • こういう層のインフラエンジニアが活躍する場が少ない、ヘタするとBIOSいじってる人とかもいる
    • HPCの人が多い、チューニングで飯を食う人はカリカリに使い倒す
  • Nifty, IDCF, さくらはスタートアップ半分、大企業半分みたいな感じ?
    • さくらは個人はそんなにいない、スタートアップが大体
      • 物理から移転したいユーザが多い
      • 基本的には現状のサーバをエミュレーションする形で提供している
    • NiftyCloudは全くの個人は使えない、ほとんどエンプラ、8割位?
      • 既存環境とL2で繋いだりするのがウケてる
      • どこのクラウドもユーザ層似通ってきてるのでは、という印象
    • IDCFも昔はほとんど個人がいなかったが、最近500円クラウドの広告などで増えてきた
      • 大規模に使うのはゲームのユーザーとか
      • VMware元々使ってる人が
    • あんまり見えないのがAzureだけど...?
      • 入って半年で結構幅広く、セグメントによって全然客層が違うがソシャゲからエンプラまで、CMSをIaaSでDRBD頑張ってる人とかも見ている
      • 「AzureはLinuxも動きます」
      • 実は小薗井さんのDrupalUGでAzure使ってます
        • ベンダロックインから意識的になると客観的にサービスやトレンドを見れる
  • 意外とPaaSは多くない、PaaSで超生産性を高めてる人もいる
    • VisualStudioは素晴らしい
  • 一般論として、どうしてPaaSは盛り上がらないのか
    • CloudFoundry?OpenShift?
    • あるいはRDS/Microservicesみたいなビルディングブロック?
      • 「自分のアプリを動かすもの」?「XXX as a Service」?
    • Hadoop as a Serviceみたいなやつを組み合わせてAWSスタックに近い
  • 「〜〜〜 as a Service」の時点でSaaSだと思います
    • 自分のアプリを作る上でデプロイとかを整備するもの、Herokuとか、をPaaSを呼ぶべきでは
  • Microservicesのようなもの、単機能のものの寄せ集め、SpringBootとか...
    • SOAとは?という話になりそうなので中段
  • 日本の場合はIaaS使いたい人が多い、その次にIBaaS、という感じ、まだまだそこからぬけ出せてないのでは
  • EC2が出た頃はNWを想像してなかった
    • ところがここ最近でNWが作れる、というの謳われだした
    • NWを意識しなくてよかったのが再び意識されだしたのでは?
    • さくらは意識させているように作っています、そして流行っているものは正しい
  • AWSからVPCが出た時、VPCを作らないとEC2を作れないようになってちょっと悲しくなった
  • AzureのWorker/Webがなくなった
    • 既存の運用のセオリーを頭に持ってこないと使い方がわからなくなる、という部分がありそう
  • ACLとSGが分離のしたのは最悪だったと思います
    • でもどうせ全台にパブリックつけてるでしょ?という話なのでは
    • さくらはほとんどそういうことはないです
      • GWをがっつり提供しているからなのでは?
  • VPC提供はクラックされるサーバが増えてきたからでは、というのがありそう
  • 感覚的にはフラットだとクラウドネイティブっぽく、VPCがあると既存スタックを持ち寄る感覚が強い
  • SoftLayerはスイッチ・ルータもベアメタル?
    • NW周りで
  • 個人的にはフラット+SGみたいなのがあればそれでいいのでは、と思うが学習コストの問題に落ち着くと思う
  • クラスAが枯渇しそうな人?

  • 今この状態を続けて幸せですか?
    • IaaS寄り、学習コストの問題...
    • 結局は見返りがあれば、という話になるのでは
    • もしかしたら幸せな定時退社の世界があるのかもしれない、そのために頑張るというのは大いにありそう
  • 学習コストが本当の敵?
    • Nifty: 会社が認めてくれるかどうか、というのがほんとうによく聞く話
    • IDCF: 周りの人がやりだした、時代の流れで変わってくる、というのも十分にある
    • Cloudn: 結構クラウドやっていきましょう、となるが現場の意識の差はわりと大きいことがある、マインド
    • さくら: 基本的には時代の流れ、EC2を始めるのにそんなにコストが高かっただろうか? いまNWが盛り返しているのはNWを触っている人たちがユーザになってきたとも言えるのでは
    • MS: 先進的なユーザは気づいていて使っている、その時にどれくらいの情報が転がっていてどれくらい勉強させてくれるか次第 全体的な流れはまだまだIaaS
    • VMware: 互換性から話をすると学習コストと検証コストを考えてIaaSを選ぶ人がやはり多そう、一方でアプリのアーキテクチャを変えないと価値が出ないというのも分かる人はわかっている
  • Cloud Enabledになるために、次から作るアプリから検証されだすのでしょう
  • クラウド事業者として...
    • 学習コストの裏にはヒト・モノ・カネがある
    • クラウドを使うからといって最適化されたアーキテクチャで動かそう、ということはない
      • 運用が面倒だからクラウドに行きたいだけの人もたくさんいる
    • 次期システムはAWS、ただベースは旧システムベースなのでCentOS5/PHP5.2/qmail/Apache...ということが往々にしてある
    • アーキテクチャ刷新=開発リソースを食うことが許されないユーザはたくさんいる
  • IaaSだからNWがくっついてきたのではないか?
    • API Gatewayのような、PaaSレベルでの連携が広まっていけばまたNWの意識は薄れていくのではないか
  • ブロードキャストを通るネットワークを持っているのはNifty, VMware
    • 自分たちでもわかったりわかんなかったりする
    • 2歩先は嫌味になりそう
    • ブロードキャストをしたいのはDRBDやHAしたい人、LVS建てたい人が大半でしょう
      • オンプレを再現したい、というのが大半でしょう、ユーザのVMからはブロードキャストできるように見せている
      • 結局は再現できる、ということは
  • 裏を返せば、世の中のほとんどのシステムは投資をする価値が無い、という経営判断がなされているとも言える
    • 現場から経営を説得できていない
    • 現状それを出来るとすればコスト削減がキモでしょう
    • 小さな鉛筆でどうにかすることに慣れると、大きな鉛筆でやることが思いつかなくなってくる
      • 定時退社の本当の問題は?
      • 自分のやりたいことができないインフラエンジニアの敵は?
  • ITインフラの人たちは社内がお客さんのことが多い
    • SOR/SOEの話題が上がっている
  • 運用の問題を解決するためにXaaSにシフトしていこう、というニーズがあんまりないのでは
  • 経営で考えると、クラウドやるより減価償却したほうが圧倒的に安い
    • それに打ち勝つためには人件費削減、定時退社はマストになる
    • やはりグッバイSSHに話は戻る
  • BSからPLに変わります、という話ではなく、こう人件費が浮きます、という話
    • VMware: 他のクラウドよりウチの方が自動化してるから楽ですよ、みたいな話し方をすると怒られるけど...
      • Googleが歌っているライブマイグレーションをvMotionは昔からやってました
      • 現場のニーズに応える、それを持ち上げる
    • IBM: SoftLayerも裏は驚くほど少ない人数でやっている、残業してる様子はあんまりない
      • ベアメタル運用を含めても
      • 外資系でも同じパターンが見られる、だいたい海外は定時で帰っている
      • 別の問題も見え隠れする
  • ハウジング・コロケーションを持っている事業
    • さくら: ハウジングが必要なユーザはどうしてもいる、逃げですがケースバイケース
    • Nifty: DC専業でもNM専業でもHWでもなく、何も持っていない、もともとクラウド利用者の会社です
      • ユーザが演るようなサービスをやるためにクラウドを始めた、というのが一番の強みでは
    • Cloudn: DC部門が一番儲かってます、クラウドは儲かりきれてない
      • APIを上手く生かしてもらって、クラウドでもベアメタルをやっていくのではなかろうか
      • 初期投資を抑えるならクラウドで...
    • IDCF: エンジニアとしてオンプレでなくクラウドを使うことをどう説明しますか?
      • 早く環境が用意できる、とかで説明することになるだろう
      • Nifty:'09の頭に大激論があった
        • あわやAWS使うか、となった時に「作ったら楽しいです」と言って始まった
          • ✕「超便利だから使うか」○「超便利だから作るか」
        • 正解はエンジニアのモチベーションです
          • 楽しいことをやりましょう、できたらその動機を下の世代に伝えていきましょう
  • 答えのないところに問を求めてはいけない、というのが結論です