クラウド運用３足の草鞋151102

Copyright ©2015 Sigmanyan All Rights Reserved.
二足の草鞋どころか三足はいてる
オレが感じたクラウド運用
SI、自社サービス、導入コンサル
３つの視点で見たクラウド運用
confidential
2015年10月31日
Keiichi Hashimoto

自己紹介
2
橋本圭一（ハシモトケイイチ）
シグマコンサルティング株式会社
Microsoft Azureコミュニティ「JAZ」コアメンバー
FacebookのJAZUGにご参加ください。
■お仕事
ECのPaas Commerbleの提供
Microsoft Azureを活用したサービス開発
Microsoft Azure導入コンサル、MSP
■趣味
おバカアプリなど技術の無駄遣い志向
Twitter @k1hash

JAZUGのご紹介
 Japan Azure User Group
略称：JAZUG(じゃずゆーじー)
 コミュニティ活動概要:
「Azureを通じて、技術、交流、実ビジネスを楽しむ。」“ちょっと興味がある
=ゆるふわな方”から“実ビジネスで使うんだよね”な方まで大歓迎！ゆるふわコ
ミュニティです。
 GROUP はFBで。Japan Azure User Group
https://www.facebook.com/groups/jazug/
 大阪(関西Azure研究会)、福岡(ふくあず)、仙台、名古屋、札幌、Azureしなの、沖
縄
 一緒に運営してくれるメンバーを募集中です。

関西Azure研究会もよろしくお願いします
メンバーは120名くらい
FBで関西Azureで検索。
リーダー＝かめぶちさん
「ブチザッキ」で著名
Azureの情報で
日本で最も充実

Copyright ©2015 Commerble All Rights Reserved.
confidential
クラウドの運用を語るには
ツール、文化、お金(ビジネス)の側面から
ツール文化お金

クラウド運用３足の草鞋151102

confidential
そして、コンテキストによって異なる
What is your Context?
クラウドとどのように関わりますか？
・サービス提供企業の(開発、運用、情シス)
・SIer
・MSP(Managed Service Provider)
・他

confidential
サービス提供企業 --- --- ---
SIer --- --- ---
MSP(Managed Service
Provider)
--- --- ---
他、情シスなど
あなたの背景によって最適解は異なる
コンテキストによってツール、文化、お金が異なる
ツール文化お金コンテキスト

confidential
クラウドの運用を語るには
お金(ビジネス)と文化は運用の目的であり、
ツールは結果と考えている。
ツール
文化
お金

confidential
３社での運用経験をお話します
３社やっているのは非常識な感じですが、
３社のクラウド運用は近しいことも、異なること
もあるので、良い機会ということで見直しました。
Commerble
EC PaaS
Sigma Consluting
SI
Cloudlive
MSP

confidential
サービス提供企業のクラウド運用
※ECのPaaSを提供するCommerble社の場合
13

confidential
Commerble EC PaaS
・ECのPaaSをサービス提供
・年商数億円以上の中、大規模のEC
・カスタマイズに柔軟に廉価に対応
・PKGと自作の高コスト、使い捨てからの解放
・高パフォーマンス
・テナントは現在10社程度

confidential
EC PaaS で利用している主なサービス
Route53(DNS)
Cloudfront(オリジ
ン用CDN)
S3(ログアーカイブ)
VNet(VPN)
VM(コンピューティン
グ)
SQLDatabase(RDB)
RedisCache(セッショ
ン)
ストレージ(プロビ
ジョニング用)
KeyCDN(リソース
用CDN)
NewRelic(監視)
Logentries(ログ)
JIRA(課題管理)
BitBucket(ソース管
理)
Bamboo(CI)
Hipchat(通知)
Other Service

confidential
EC PaaSの構成
AWSでネットワーク、Azureでコンピューティング
監視、ログ、ソース管理、CIを外部サービスで利用。
コンピューティングマネージドサービス
オンプレミス
VPN
Route53 Cloudfront
S3
仮想マシン
仮想ネットワーク
SQL
Database
RedisCache
Storage
Blob,Queue
監視
ログ
ソース管理、CI
Front
Admin
API
DC
Task
オリジン
リソース
immutable
プロビジョニング

confidential
DevOpsについて考えてきたこと
DevOpsが役割として分かれるのは良いこと。
が、DevとOpsが分離して進むと
Ops=監視したい値が取れないとか
Dev=実装した機能をデプロイしてくれないとか
双方の正義が衝突がする

confidential
DevとOpsは仕事が異なる
Ops
・システムの安定稼働
・安定している所に不安定要素を載せたくない
Dev
・機能を作らないとサービスを向上できない
衝突しないにはどうすればいいか？？

confidential
DevとOpsが衝突しないためには
安定稼働をしているところに不安定が入ったら
いつでも切戻しできるようにすればよい。
※切戻しをOpsに許容してもらう
CI(Integration)→CD(Deploy)→CT(Test)
なので、このツールセットを選んだ。
※課題とソースとビルドとデプロイが紐づいて
いて、いつでも戻すことができるように

confidential
哲学の結果＝切戻しを容易にする
Bamboo＋プロビジョニング機能で指定リビジョンをリリー
スでき、切り戻しも可能。その為に選んだ構成。手段。
コンピューティングマネージドサービス
オンプレミス
VPN
Route53 Cloudfront
S3
仮想マシン
SQL
Database
RedisCache
Storage
Blob,Queue
監視
ログ
ソース管理、CI
Front
Admin
API
DC
Task
オリジン
リソース
immutable
プロビジョニング

confidential
安定稼働とメトリクス
何が安定か安定状態を規定することが必要
メトリクスをとらないとわからない
＝安定状態を逸脱したことを検出できる
Dev=メトリクス取れるよう、Configで切替できるようにする
Ops=アラートから内容を把握し、状態を回復する
※ECだと受注が監視できている状態
＝これを継続的に回す

confidential
DevとOpsが仲良くなるメリット
DEVとOPSが仲良くなって、マーケットに届けば
ビジネスが成長する。
知恵を出すだけでコストも下げ、直接利益に貢献する
個別最適のみせず、全体最適。
スパイラルで良くなっていく。
それをやったら、これをすてるというような状況が出ない
ようにする。

confidential
他の例）実装における工夫
例）管理画面からデータを一括アップロードしたい
普通のCSVだとカラムの並び順などで処理してしまうが。。
考）ヘッダーにマッピングのカラム名が入っていればよい。機
能の増減もあるので、４カラム５カラム、データ入稿で好き
な使い方をできるようにする。
製品のライフサイクル＝ECは数年と長い
ライフサイクルを踏まえ、どういう設計にするか
プロダクトの寿命を考えると柔軟性が重要。

confidential
マルチテナントと製品寿命
マルチテナントと製品寿命が長いのを考慮して作る
何を解決する仕事と思っているかが大事。
SIの解決方法とは大きく異なる。
サービスは規模によって、今後の方法論を変えていかなければ
ならない。今のテナント数だとよくても、物理とかIOとかに
ぶつかる方法論を使っていたりもする。
コストを下げるため、集約するほど問題になっていく。
※これらテナント数の問題については事前に見えている

confidential
マネージドサービス組み合わせのコスト感
各サービス数ドル程度からの利用で人手のかからない強固なイ
ンフラが構成できる。結果、低コストで人手が少ないと、
サービス価格を落とし、競争力を高めることができる。
Other Service
数十ドル数十ドル
数十ドル

confidential
工夫＝リソース用CDNの価格を抑える
例えばKeyCDNはCloudfrontの半額

confidential
BizSparkという最高のスタートアップ支援
PlusだとAzureが月100万円、利用可能
※スタートアップ支援として最強

confidential
予定＝コンピューティングの仕入れ値を下げる
AzureのPre-Purchaseプランを活用予定
1年分事前払いで最大63%引き

confidential
SIerのクラウド運用
※Azure上のSIを提供するシグマ社の場合
32

Copyright ©2015 Sigma Consulting All Rights Reserved.
confidential
Azureを活用してサービスを作るSI企業
33
イノベーションを生み出す力
Commerble EC PaaSによる
柔軟性の高い開発
SiteCoreによる
大規模CMSの豊富な経験
Microsoft Azureで
日本をリードする実績
Microsoftをはじめ、
大規模サービスを運営する
企業からの信頼も厚い
高い技術力を持ったエキスパート集団
クラウド、最新技術を活用
迅速、柔軟な成果
更なるイノベーション
大規模サービス、ポータル、ECをクラウドで迅速に実現
※Azureでの構築実績＝規模大小あり60案件くらい

confidential
PaaS＋マネージドサービスで楽して迅速に
シンプルな構成、極力複雑さを避ける
コンピューティング(PaaS)
WebApps(サービス、管理者サイト、ジョブ)
Microsoft Azure データセンター
ストレージ
Blob静的ファイル配置、他CSVなど
マネージドサービス
永続化領域(データベース、ログ)
Git Hub等からのデプロイ
SQLDatabase
Redisキャッシュ
モニタリング
Express Route
外部接続
マーケットプレイス
Blob
オンプレミス
課題管理、
コミュニケーション

confidential
クラウドデザインパターンは重要
MSのデザインパターン＝設計、実装寄り
Azure CloudDesignPattern 検索
AWSのデザインパターンとは違う切り口
クラウド上での汎用的な設計と実装
※アーキテクト、実装者は読んだほうが
よい良書。
※英ドキュメントは無償
※JAZUGコミュニティで翻訳出版

confidential
デザインパターンの運用ケーススタディ
■最近あったこと
EX）１か月で50万人が登録するアプリ(秒間＝100)が
リリース後、30分で50万人登録するアプリに変貌。
秒間＝数千に。
→どうするか？

confidential
クラウドデザインパターンの知見を使う
50万人30分に耐えるように再設計、改修(約半日で)
Asynchronous Messaging Primer
・RDBへのINSERTがボトルネックに、非同期に
Cache Aside
・RDBへのREADがボトルネックに、Cacheに退避

confidential
50万人30分のコスト感
・RedisCacheの月２万円分
・Queueの数十円分

confidential
SIでクラウドに携わる際考えていること
サービスで収益や成果を上げないとビジネスが続かない。
ただでさえ、すんなりとはうまくいかない新規事業が多い。
速度を優先する。
成果を上げるために、実装したビジネスの結果を極力早く知る。
すべての機能を実装する前にリリースも提案する。
ロジックとビジネスに注力して、シンプルに、楽に運用する必
要がある。その後、しがらみなく、改善を続けていきたい。
※技術と体制(ビジネス)のしがらみは常に改善

confidential
SIerとしての進化？
コンピューティング、バッチ、SQLDatabase、
ストレージ、キャッシュ、メール(SendGrid)
マネージドサービスで毎回ほぼ足りる
つまり、シンプルな構成にすることが大事
PaaS+マネージドサービスだと
一人のエンジニアがDevとOpps両方できる。
これはSIerとしての進化だと考えている。

confidential
PaaS,Manged,Speed.
※迅速なPaaS+マネージドサービスで良い。

confidential
マネージドサービスは便利であるが懸念も
構築時に存在していない機能、マネージドサービスがあるので、
構成したタイミングによって構成、設定が微妙に異なる。
※技術的負債になるケースもある。
A案件＝CloudService(旧型のPaaS)
B案件＝WebApps(2013年の機能)+Cache(Roleベース)
C案件＝WebApps(2015年の機能)+RedisCache
保守するエンジニアでも最新情報のキャッチアップと
設計や設定を見直す力が必要。※情報の共有も

confidential
最新の機能を熟知する
例えば、SQLDatabaseのPoint In Time Restore
5分間隔でのバックアップと特定時点に戻せる
こういった情報を知っているか否かで運用は大きく異なる。

confidential
ディスコン発生時
■ディスコン発生時の費用
より良いサービスが出た場合、乗り換えが可能だったり、
ディスコンとなるサービスも存在する。後あと回避できない状況
が発生することもある。
が、目に見えない、顧客への変化が出にくいケースでは、
費用を確保しにくい。
一般的に別の手段が提供されるので大きな心配は不要だが、
マネージドの弊害として予め伝えておく必要がある。

confidential
アプリケーション保守について
「楽なんでしょ？」保守費を減らしたいという顧客も。
従来と同じお金(保守＝高利益)の考え方ではいけない。
ネットコマース株式会社
最新のITトレンドとビジネス戦略/
2015年10月版/ビジネス編
■顧客への還元
◇ノウハウの還元
・最新の情報を知り良いものを提案
◇コストの還元
・PaaSの方を安くする
・工数積算からの脱却

confidential
ノウハウ還元＝最新情報の検証、提案
新しいもの、特にコストや手間を補う便利なものは
積極的に試して提案する。
情報はチームで共有して提案していく。
SQLDataWarehouse
PowerBIの話など。
※BIが廉価に。

confidential
コスト還元(PaaS + Managed)
我々の推奨構成を価格と納期に反映する。
顧客は他の環境とチョイスすることによって、
コスト還元を知る。★単にクラウドが安いわけではない

confidential51
悩み＝工数積算の限界
月額で１万円は安くなる実装がある
が実装に数日はかかり20万円ほどのコスト
やるべきか。回収には２年かかる。
後の顧客でスケールすることであればやるべき?
今の顧客でもらえないなら、やらない?
→工数積算型の考え方では成立しない

confidential52
悩み＝工数積算の限界２
先ほどの30分50万人対応
知見とクラウドデザインパターンで解決。
誰にもできることではない。
いくらもらうべき?
→工数積算型の考え方では成立しない

confidential
我々はポストSIの世界に来ている
クラウドの効果的な運用はポストSIビジネスの世界では
工数積算から離れた考え方が必要
ネットコマース株式会社
最新のITトレンドとビジネス戦略/
2015年10月版/ビジネス編
スモールかつ迅速なスタートであれば収益
構造の検証を行いやすい
・サブスクリプション
・レベニューシェア
・成果報酬

confidential
SIerとお金、工数積算からの脱却
クラウド運用の世界、工数積算から脱却する
SIerはお金のもらい方を見直すチャンスにある
お金のもらい方は哲学(文化)に影響する。
・納品しない開発
・レベニューシェア
・成果報酬
シグマではクラウドを背景に色々試した。
良くも悪くも色々な経験があるので、まとめ中。後日。

confidential
オマケ）MPNを活用した売上
Microsoft Partner Network
顧客のAzure消費費用からキックバックを受ける

confidential
MSPのクラウド運用
Azure上のコンサル、
運用監視を提供するCloudlive社の場合
56

confidential58
運用ツール(監視と連絡が中心)
Azure内外からZabbixで監視
Backlogを活用したコミュニケーション
現在20社程度なのでスケールする際にツールは
変わっていく想定

confidential
文化(哲学)
Azureの未来につながることであれば
何でも叶える努力をする。
・情報発信の大切さ
・新サービス、新要求の検証、追及
→Azureでは、日本ではまだ…を叶える
・知見から、約束できないことを断る
→オススメできない構成の却下

confidential
問題＝啓蒙が足りない
顧客からの問い合わせ
「Azureがおかしい」
「Azureか顧客マターか、その中間か？」
→切り分けが重要
アプリケーションがおかしい
→顧客マターを減らすためには啓蒙が必要

confidential
Azure自体の啓蒙が事業に不可欠なので
Microsoftと共同で自習書を作りました
※Azure 自習書で検索。

confidential
日本DC稼働時の検証テストでバグを多数報告
日本のユーザーが安心して使えるよう様々なケースをテスト

confidential
Azureサポートの方との関係は非常に大事
問い合わせ時点での信頼関係が違う
適宜フィードバックを送りましょう

confidential
顧客要望を哲学とAzure愛で叶え続ける
MSPでは、メニューは開発され続ける
※DBの業務固有なメトリクス通知など
複雑怪奇な要望
＝叶えると売上は大きいが…
＝哲学とAzure愛に従うべき

confidential
自戒）オンプレの不幸をクラウドに持ち込むな
MSPお金を稼ぐのは大事。
だが、オンプレの不幸をクラウドに持ち込んではいけない。
●ダメMSPな行為
複雑にする＝売上増える
仮想マシン構築の金額で数十万＝自動化する能力がない
複雑にして管理しないインフラでいいのか＝管理するポイン
トがわかっていない
マネージドサービス作成１クリック５万円＝適切なお金か？

confidential
手短にクラウド運用まとめ
・ツールは手段であり目的でない。
ビジネスと文化(哲学)の結果。
・哲学はクラウド運用では不可欠。
・これらの検討過程はコンテキストで異なる。
自分の立場でよくよく考えてみよう。

クラウド運用３足の草鞋151102

クラウド運用３足の草鞋151102

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(17)

Destaque

Destaque(20)

Similar a クラウド運用３足の草鞋151102

Similar a クラウド運用３足の草鞋151102(20)

Mais de Keiichi Hashimoto

Mais de Keiichi Hashimoto(13)

Último

Último(11)

クラウド運用３足の草鞋151102