Interop Tokyo 2014 一日目 前半
Interop Tokyo 2014 一日目に行ってきたのでその報告 前半です。 登壇者の方については敬称略となります。
資料が手元にないので、各セッション、気になったところを抜粋していく感じで。 有償のセッションなので、全部書き起こす気はないのですが、どの当たりまで書いていいのか悩ましいです。
私の感想については、「感想」と書き、その他の記述はすべていずれかの登壇者の発言（意訳はあり）です。
1.急激な進化を遂げるSSD新技術のロードマップ
登壇者
- さくらインターネット株式会社:田中 邦裕
- 株式会社東芝 セミコンダクター＆ストレージ社:田中 陽一郎
- 日本サムスン株式会社:岡田 圭介
- インテル株式会社:田口 栄治
内容
- SSDは普及期に入った。もう、結構普通に使われている。
- 今年は、PCI-E系のSSDの普及の歳になるのではないか
- インターフェース（SATA、SAS）はネック。PCI-E、メモリのBUSなどインタフェース周りは変わる
- SSDの選択ポイントとして、みんな気にする速度、耐久性以外で、『速度のバラ付き』はかなり重要
- Intelでは、Intel® Cache Acceleration Softwareといったレイヤーにも力を入れてる。
- SSDを支える技術としては、3d化は大きい！！（3d v NAND）
- 参考：http://pc.watch.impress.co.jp/docs/column/kaigai/20130819_611653.html
- 感想：露光とか、製造工程のイメージが一切わかない。が、コスト、技術的な影響度は相当大きく見える
- サーバーベンダーの対応はSSDの進化に追随できていない
- さくらではユーザ主導で、メーカーの保守とかと切り離して？検証、使用。
- 感想：サーバーベンダーの対応は結構不満。価格、保守体制など。保守的な現場だと、サーバーベンダー保守のせいで投入できない事例多々あり。
- コスト感。工場１個 １兆。研究費 年間一兆。売上 ５兆。全力で自転車こいでます！！
- 感想：ざっくり認識していた数字ではあるが、、、、すげえ。六本木ヒルズの総工費が2700億とかそういう桁。
総括
ただのHDDの置き換えっていうよりも、質的な転換が起こる前兆でここ５～６年は相当楽しいぞ！！という雰囲気がかなり強く漂ってました。 不揮発性メモリ、原子時計が分散システムに及ぼす影響、ストレージの変化と言ったあたりはかなり気になるところです。
ただ、不揮発性メモリ、原子時計はもうちょっと時間がかかるように見えているので、SSDによるストレージの変化が一番最初に来る感じでしょうか？
2.これからのデータセンタを知る！～DCIMによる大規模化対応～
登壇者
さくらインターネット株式会社:須藤 武文 株式会社ノーチラス・テクノロジーズ:神林 飛志 株式会社竹中工務店:小林 哲雄 エヌ・ティ・ティ・コムウェア株式会社:尾西 弘之
内容
- 下記のような立て付けで開始
- DCIMってバズワードだよね。範囲、定義が緩すぎる
- 本当に細かいことの積み重ね。
- 数字でね～と思ったら床下ケーブルのトグロがエアフロー邪魔していたり
- 温度一つでも、壁際なのか、測定ポイントはいくつなのか？サーバはどのくらいの熱量をだすのか、、などなど。
- 電気代 1/3ぐらい（といっていたはず）
- 感想：電気代が高いというより、サーバ代が安い？？自分の買っているサーバのコストだと、PUEが2.0とかでも電気代の比率そんなにいかない・・。 * 神林さん。DCの管理会計、原価計算について。 * さくらの原価計算 やってます * DC屋さんの原価計算とかドンブリ。コスト積み上げて、ラックとか、面積で割るだけ。 * 電力代とかのランニングコストが高くなっている現状、このドンブリはまずい。 * まじめに分析している企業に、ドンブリでは勝てない * この辺りの企業淘汰が流通、卸では起こり、企業数が1/100とかになった * 感想：ちょっと、調べる必要あり。話し聞いてビビった * ITのリソース使用はピーキー。一部のユーザがIOPS、ネットワークを、、、 * どのようなユーザが同インパクトを及ぼしているのか、把握しサービスメニューを考えていくことは重要 * これが、サクラDCの管理会計モデルだ！！（箱が20個ぐらいの分析モデル提示） * 感想：しっかり後で見たい。公開されるのか？？
- 機械系の部分はかなりデフォルトでセンサーが入っており、詳細なデータが取れる
- ただ、計算量的にあれなので、asakusaとか、Hadoopとかじゃないと分析回しきれんけど
- というか、コストモデル作るのもかなりムズい
- 感想：計算量よりも、業務分析のほうがきつそう、、、
- 質問者：規模の経済的な話ってあると思うのだけど、DC事業のための最低規模についてどう思うか？
- 回答；最低規模なんてものはねえ。弱み、強みを分析して、自分でやるべきか考えろや。自営検討の一例として、ネットワークのアウトバウンドコストとか、オンプレとかとの連携回線コストの話とかある。
- 原価分析は回し始めたばかり。そのため、施策までには至っていないが、まず、見えることが重要！！
総括
神林さんの話は強烈だった。設備系のランニングコストが高い場合は、現状のセンサーとかの粒度だと難易度は高いが原価計算は可能とのこと。一方、人系の作業の不透明さ、人の職種転換不能な場合をどう分析して、どう経営判断にするかなどは非常に気になる所。 また、いきなり施策に落とすことはできなし、原価モデルを作れるわけではないが、出来る範囲での可視化の意味は大きいと思うので、kibanaとかで可視化を進めていきたい。 オンプレの良さだと、使用率が低い環境を詰め込むにはオンプレは強いと感じる（IIJのESX鯖貸しでも良い）。ユーザーはかなりマージンを取って申請してくるので、DISKのシンプロとかは実績値で50%位だし、Vmwareの場合のメモリのページ重複排除とかでも１０～２０％のメモリコストが削れていたりする。 一部のピーキーなユーザーをちゃんと分析しAWS等に追い出す等の施策をすれば、オンプレの価値は保てるのではないか？ また、docker等を使うとAWS等を使いつつ一つのコスパのいいインスタンス使いコストを削りつつ、複数のアプリケーションを詰め込むといったことがやりやすくなるが、管理コスト等を考えた場合有効なやり方になるかが、まだ個人的に見えていない。
R その１
はじめに
自分用のメモ書きです。他のサイトのほうが情報が揃っているでしょう。
環境作成
R 3.0.2 64bit winで構築
開発環境にはRstudioを仕様
目標
基本、株価分析目的。インフラデータの解析も一応検討。
今日の試行
を参考にあれこれ実施。
インストール
install.packages("RFinanceYJ")
library(RFinanceYJ)
株価取得と表示
> sony <- quoteStockTsData('6758.t', '2009-01-01')
> nrow(sony)
[1] 1176
> head(sony)
マニュアルはこちら
http://cran.r-project.org/web/packages/RFinanceYJ/RFinanceYJ.pdf
作ったのは里さんっぽい。
説明に「Japanese finance market from Yahoo!-finance-Japan」
とあり、yahoo-finance-Japanレベルの情報（日足レベル）までしか無い模様。
ということで、今後の課題として
- 分足単位のデータを探す
- Rで扱えることが望ましいが、場合によってはInteractive BrokersのあたりからJAVAでぶっこ抜く
- Rでindicator関連（テクニカル指標）のパッケージがあればよいが、場合によってはMT4との連携を検討する
- 自分の知っている中ではMT4がindicator関連では最強な印象。
という感じで一旦クローズ。
SIとしてできるDevOps DevOps Day Tokyo 2013を聞いて
結論
SIでも出来るDevOps的な取り組みはある。
特に、ビジネスメトリクス、インフラメトリクの収集、見える化が良いのではないか？
エントリのの内容
DevOps Day Tokyo 2013を見てSI所属の人間が考えたことです。
セッションの内容に関する情報はあまりありません。
セッションに関する情報は下記が参考になります。
DevOps Day Tokyo 2013 参加レポート
http://jedipunkz.github.io/blog/2013/09/29/devops-day-tokyo-2013-report/
http://jedipunkz.github.io/blog/2013/09/29/devops-day-tokyo-2013-report/
そもそも運用がない！?開発がなくなる！？
SIのシステムの中には開発して納入して終わり。運用は完全にお客様まかせ
ってパターンもあるので、まず開発、運用のパターンから整理します。
- 納入後契約関係が切れお客様が完全に運用をやるパターン
- 問い合わせが頻繁に来るパターン
- 問い合わせがこないパターン
- SIが継続的に開発し、お客様が運用するパターン
- 客先常駐で開発するパターン
- 自社開発するパターン
- 開発、運用を一括して委託されているパターン
- サービスレベルさえ維持していれば運用がいろいろ出来る権限のあるパターン
- 権限、オペレーションが限定されている運用のパターン
パターンごとに、何ができそうか書いていきます。
納入後契約関係が切れお客様が完全に運用をやるパターン
問い合わせが来ようとも、来なくても、基本路線としてはDEVが消滅、もしくは、大幅縮小するパターンです。そもそもの話として、継続的デリーバリーはそもそも求められていない、提供する契約体系になっていません。「変化への追随なにそれ？」とか「いや、このドメインのシステムは変化ねえよ」というのりで、とっととDEVを解散してコストを落とすことが正義のタイプのパターンです。
が、実際のところ、そこまで手離れがいいシステムばかりかというと忘れた頃に問い合わせはあったりするので、SIとしては問い合わせへの対応コストをいかに減らすか、OPSの状況をどうやって低コストで把握するか？といったことは重要でしょう。
となると役に立ちそうなのは、ビジネスメトリクスとインフラメトリクスの収集です。例えば、パフォーマンス対応の時に、一定時間の交渉をすればインフラメトリクスをお客様からいただく事はできます。しかしながら、ビジネスメトリクスをいただけることは稀です。というか、提供したシステムにビジネスメトリクスを取得する仕組みがないことのほうが多いでしょう。どういう使われ方をしているのかよくわからないまま、インフラメトリクスだけを見つつ対応することが多いように思います。これだと、場当たり的な対応はできても根本的な対応は難しいです。
また、メトリクスをとるメリットとして、予防保守、増設の提案、更新プロジェクトの受注の見通し（使用されていないシステムの更新は受注できない）など色々あるように思えます。セキュリーティーの話があるので、「リアルタイム、オンライン」でメトリクスが取れるとは限りませんが、「バッチ、オフライン」でメトリクスを取る価値は意外と大きいのではないかと思います。
また、話は変わりますが、最近のハードウェアには保守ベンターに情報を自動送信するものが多く出てきており、障害対応が簡略化できるので個人的には助かってます。SIの納入するシステムも同様の仕組みを込みこんでいくことがいいのでないでしょうか？
SIが継続的に開発し、お客様が運用するパターン
DEVがSI、OPSが顧客の場合ですね。で、DEV、OPSの物理的な距離が近い場合と遠い場合があります。また、DEVが大陸で言葉が通じなくて、かつ、連絡に数POP必要という絶望的な場合もあるでしょう・・。
この場合、やっかいのなのは下記のようなことがあるでしょう。
- 別会社であること
- 利害が一致しない可能性
- 契約、法律、コンプライアンスに縛られる
- コミュニケーションコストが高い可能性
@mirakuiさんのセッションで、「迷ったら健全な方」との話がありましたが、上記のような状況下では「健全とはなんぞや」といった状態になります。また、特に厄介なのが、決裁者、営業らの非エンジニアも巻き込んで認識を揃えなければならいない。セッションを色々聞いてやはり感じたのが、DevOpsはツールの話ではなく、またエンジニアだけの話でもなく、経営を巻き込んだ話です。
となると、会社間の経営方針、戦略、パートナーシップ、決裁者、営業時の契約といったあたりの話も重要になってきます。現場のエンジニア同士では会社をまたいでコンセンスが取れていても、上長、営業レベルからストップが入る可能性はあるでしょう。
また、直接の関係者がうまくやっても、双方の本部からPMOがやってきて、、みたいなことあるでしょう。
ということで、このパターンでどういったことが出来るのか、なにをやるべきは正直見えていません。とりあえず、思いつくところとしては下記ぐらいです。
- ビジネスメトリクス、インフラメトリクの収集、および、DEV側への開示、上層部への開示
- 物理的にDEVとOPSを近づける（建屋、部屋、机の並び、メールの経路のレベルで）
まじめに考えると頭が痛くなってくるので、『可能な範囲でやれることをみつけてやる』が落とし所かという気がします。
開発、運用を一括して委託されているパターン
DEV、OPSが同一会社の場合です。が、「OPSが権限を持っている場合」と、
「顧客から作業を委託されているだけで運用作業、運用の変更には顧客承認がいる場合」があるでしょう。
ただ、上記の差により、若干スピード間は変わりますが、いずれの場合でもセッションで語られていたDevOps的な取り組みは出来るのではないかと思います。
気になっていること DevOpsの効果測定
「Web系でサービス運用しているパターン」、「開発、運用を一括して委託されているパターン」ならば、「リリースサイクルが短く出来た」とか、「障害修正時間が短くなった」とか、それによって「離脱率が下がった」とか「新規サービスが早期投入できて売上UPです！！」みないな話はわりとやりやすい気がします。
が、SIで「ぶっちゃけ、これで利益いくら上がって、コストどんだけ下がるの？？」「予測できなくても後付でいいから、統計的に有意にメリットと示せる？？」みたいなことを言われると固まります。
SIという業態ですと、運用品質、サービス品質を上げても、それが数字（特に利益）に現れるまで時間がかかります。障害対応の時間、残業時間等のあたりはわりと早期に数字の跳ねてくるような気もしますが、これらが直接的にコストに跳ねてくるかというとコストは人月で決まるので、「みんなが心穏やかに平和に過ごせるだけでコスト変わってません。死亡率だけ下がりました。」みたいなことはありそうです。
ということで、DevOps自体のメトリクス、システム開発、運用のメトリクスってどうするんだ、、、というのが自分の中では課題です。
最後に
DevOps Day Tokyo 2013非常に良かったです。正直なところ、まじ、頭いたいわーみたいな感じはあるのですが、メトリクス取得はわりあいどの状況下でもやりやすいと思うので、まず、出来るところからといった印象です。
