- 2015年9月28日(月) 19:00-20:40
- TKP新宿カンファレンスセンター
- https://sakura-kanto.doorkeeper.jp/events/30638
- ハッシュタグ: #さくらの夕べ
- 分散コンピューティングが一般にも普及している
- Hadoop が代表
- 原価計算を行うシステムを作った
- まず Hadoop を使いたい
- 本末転倒だけど CPU リソースをたくさん使う例が欲しい
- サービス化を検討した
- なんでも自社で賄うので原価計算が難しい
- 上流に近いところから部品を買って組み立てている
- 部門ごとに利益を正確に把握していない
- 全体最適をした方が良い
- VPS は原価が高い
- トラフィックがすごく増えた
- トラフィックはたくさん仕入れると単価が下がる
- VPS のおかげで他のサービスの通信単価が下がる
- 本当に儲かっているかどうか分からない
- 原価を分解して解析したい
- ノーチラスの神林さんができると言っていたな
- かなり細かい粒度でやりたい
- 10万以上の VM がそれぞれトラフィックを吐いている
- 海外にトラフィックを出していると単価が高い
- IX に出すと安い
- サーバによって CPU の計算資源単価が変わる
- 当然データセンターの場所によってコストも変わる
- データを貯めて保持することを社風として浸透させよう
- CPU 資源の使い方として、自社でドッグフードを食わなければいけない
- これまで不可能だった粒度の細かい原価計算を自動化する
- 制度会計と管理会計
- 管理会計がないと、適正な利益がいくらなのか分からない
- 「所有から利用へ」
- 誰かが「持つ経営」をしなければならない
- さくらはそれをする役割の会社
- これまでは業界全体がけっこうザルだった。
- 投下資本より売上総額が上回っていれば、見かけ上問題はない
- 損益が悪化していくると、何が原因か解析して適切に改善策を打たなければならない
- 「金額」という一次元の尺度で折りたたんで評価する
- まずは石狩専用サーバ1台を1人の客が使うというモデルで、バッチを走らせる
- 徐々に対応サービスを増やした
- 今となってはさほど大規模でもない
- データソースが60種類くらい
- 一箇所のストレージに多くの種類のデータを入れて、一つのプログラムで呼ぶ例は珍しい(神林)
- サービス構成するコストをモデル化
- 土地代
- 発電所代まで
- IMPI を通して各サーバの電気消費量も見れるものは見ている
- W秒で保持している
- モデル構築言語は Asakusa の DSL
- DFD (Data Flow Diagram) から循環を取り除いた DAG (Directed Acyclic Graph)と呼ばれるもの
- 500GB/日
- 全サービスに拡大するともっと増える
- 1日1TBを超えると日本としてはビッグデータと言って良い (神林)
- 世界では PB 以下のものはビッグデータとは呼ばない
- TB を超えると処理が詰まってくるので RDB では不可能なレベルになる
- 当然 Hadoop
- Asakusa Framework + MapR
- 原価計算を分散で行うのは世の中的には普通?
- 全然普通じゃない、そんなことをやる人はいない (神林)
- 普通は原価計算は RDB を使う
- 複雑なのは自動車
- 最も複雑なのは航空機
- RDB だと group by の嵐になって遅くなるので、非正規化の嵐
- 複雑になって誰も触れない
- 「電卓を猛スピードで叩くシステム」(神林)
- 自動化されているものはまあいい
- 主に機械が生成するログ
- 自動化されていないものが厄介
- 人間による人間のためのデータ
- データとして利用されていることを意識していない
- 現場のオペレーションを変える?
- 本来は観測システムなので本末転倒
- レポートを月次で出せるようになった
- データセンターごと、サービスごとの利益
- 社内データの整備と改善
- 課題の洗い出しができた
- まともな原価企画への基礎ができた
- みんな Excel で変な表を作らなくなった
- さくらさんは少数精鋭
- 結果的にこれが成功要因
- 原価計算は基本タコ壺になる
- 微妙な仕様は常に役員の方が決定していた
- 社内の全社的な協力
- さくらさん側のコミットがとても高かった
- ユーザのコミットメントで全て決まるのが SI
- 同じことをやってもユーザコミットがなければ絶対に失敗する
- ノーチラス側としては6名体制
- 典型的な Phased アプローチ
- ウォーターフォール
- 神林さんはアジャイルが嫌い
- 変更も見越して WF をやっているので、アジャイル寄りではある
- Hadoop で前処理
- Spark で計算処理
- おそらくこの組み合わせは今後デファクトになる
- 出力は Excel
- JDBC で叩く
- モデリングツリーがどうなるかという設計は、ほとんどさくらさん側で行われた
- 毎週課題が出る
- 新サービスの対応とか
- プラットフォーム変更
- Hadoop で進んでいたのですべて Spark に書き換えるのは難しい
- Asakusa 側でコンパイラを Spark 向けに書き換えた
- Spark すごい
- Hadoop が木製バットだとすると Spark は金属バット
- ほぼすべてのワークロードで Hadoop より早い
- もし Spark の方が遅かったら、そのモデルの設計が悪い
- 神林: このシステムの特徴
- アクティブベースコスティング (ABC)
- 原価計算屋の夢を実現している
- さくらさんのケースは 99% 間接費なので、従来の方法では計算できない
- これは間違いなくリーディングケースになる
- 一時銀行が ABC をやろうとしたが失敗した
- 計算が終わらなかった
- データが取れない
- 田中
- IPMI は驚くほどたくさんのデータが取れる
- 須藤
- BMS (Building Management System)
- 建物を管理するシステムが古い、Windows XP で動いている。
- IE は 9 まで
- 精度が悪い部分、データがそもそも取れない部分もある
- 神林
- やはりネットワーク機器
- 物理結線くらい自動で取れるものだと思ったら、取れないので驚いた
- 須藤
- データに対する取り扱いが至っていなかった
- Excel の使い方が人間向きだった
- 田中
- ラック管理システムってまだ動いてないんでしたっけ?
- 須藤
- 今その話をするんですか?
- 田中
- 社内でなんとか管理システムが山のようにある
- 須藤
- 所有から利用へ
- 所有する側にまわりずらくなってきている世の中
- 淘汰されてきて少なくなってきている
- 神林
- 分散処理を提供する観点ではサービス化しかない
- 5年くらいすれば DB はすべて分散化する
- 分散 DB の設計は非常に難しい
- A 社でさえトラブルで落ちた
- 田中
- ムーアの法則はそろそろ終わる
- CPU の微細化がそろそろ限界
- 我々は最近「データセンター屋」と名乗らないようにしようと言っている
- 海外、国内のビッグプレイヤーと勝負しなければいけない
- スキマで改善していかないといけない
- ラックの最適配置も始まっている
- ムーアの法則はそろそろ終わる
- 須藤
- タイトルに釣られてきた皆さんすいませんでした。
- サービス化もやりたいと思っている
- この内容に興味がある方はぜひコンタクトを
- 神林
- 開発はさくらのクラウドでやっている
- 他のクラウドサービスと比べてもパフォーマンスは良い
- 田中
- 事例が増えてトータルのコンピューティング量が増えればやる意味がある