クラウド運用３足の草鞋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しなの、沖縄

一緒に運営してくれるメンバーを募集中です。

https://www.facebook.com/groups/jazug/

関西Azure研究会もよろしくお願いします

メンバーは120名くらい

FBで関西Azureで検索。

リーダー＝かめぶちさん

「ブチザッキ」で著名

Azureの情報で

日本で最も充実

Copyright ©2015 Commerble All Rights Reserved. confidential

クラウドの運用を語るには

ツール、文化、お金(ビジネス)の側面から

ツール文化お金


そして、コンテキストによって異なる

What is your Context?クラウドとどのように関わりますか？

・サービス提供企業の(開発、運用、情シス)・SIer・MSP(Managed Service Provider)・他


サービス提供企業 --- --- ---

SIer --- --- ---

MSP(Managed Service Provider)

--- --- ---

他、情シスなど

あなたの背景によって最適解は異なる

コンテキストによってツール、文化、お金が異なる

ツール文化お金コンテキスト


クラウドの運用を語るには

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

ツール

文化

お金


３社での運用経験をお話します

３社やっているのは非常識な感じですが、３社のクラウド運用は近しいことも、異なることもあるので、良い機会ということで見直しました。

CommerbleEC PaaS

Sigma ConslutingSI

CloudliveMSP


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

13


Commerble EC PaaS

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


EC PaaS で利用している主なサービス

Route53(DNS)Cloudfront(オリジン用CDN)S3(ログアーカイブ)

VNet(VPN)VM(コンピューティング)SQLDatabase(RDB)RedisCache(セッション)ストレージ(プロビジョニング用)

KeyCDN(リソース用CDN)NewRelic(監視)Logentries(ログ)

JIRA(課題管理)BitBucket(ソース管理)Bamboo(CI)Hipchat(通知)

Other Service


EC PaaSの構成

AWSでネットワーク、Azureでコンピューティング

監視、ログ、ソース管理、CIを外部サービスで利用。

コンピューティングマネージドサービス

オンプレミス

VPN

Route53 Cloudfront

S3

仮想マシン

仮想ネットワーク

SQL Database

RedisCache

StorageBlob,Queue

監視

ログ

ソース管理、CI

FrontAdminAPIDCTask

オリジン

リソース

immutable

プロビジョニング


DevOpsについて考えてきたこと

DevOpsが役割として分かれるのは良いこと。

が、DevとOpsが分離して進むとOps=監視したい値が取れないとかDev=実装した機能をデプロイしてくれないとか

双方の正義が衝突がする


DevとOpsは仕事が異なる

Ops・システムの安定稼働・安定している所に不安定要素を載せたくない

Dev・機能を作らないとサービスを向上できない

衝突しないにはどうすればいいか？？


DevとOpsが衝突しないためには

安定稼働をしているところに不安定が入ったらいつでも切戻しできるようにすればよい。※切戻しをOpsに許容してもらう

CI(Integration)→CD(Deploy)→CT(Test)なので、このツールセットを選んだ。※課題とソースとビルドとデプロイが紐づいていて、いつでも戻すことができるように


哲学の結果＝切戻しを容易にする

Bamboo＋プロビジョニング機能で指定リビジョンをリリースでき、切り戻しも可能。その為に選んだ構成。手段。

コンピューティングマネージドサービス

オンプレミス

VPN

Route53 Cloudfront

S3

仮想マシン


SQL Database

RedisCache

StorageBlob,Queue

監視

ログ

ソース管理、CI

FrontAdminAPIDCTask

オリジン

リソース

immutable

プロビジョニング


安定稼働とメトリクス

何が安定か安定状態を規定することが必要メトリクスをとらないとわからない＝安定状態を逸脱したことを検出できる

Dev=メトリクス取れるよう、Configで切替できるようにするOps=アラートから内容を把握し、状態を回復する※ECだと受注が監視できている状態＝これを継続的に回す


DevとOpsが仲良くなるメリット

DEVとOPSが仲良くなって、マーケットに届けばビジネスが成長する。知恵を出すだけでコストも下げ、直接利益に貢献する

個別最適のみせず、全体最適。スパイラルで良くなっていく。それをやったら、これをすてるというような状況が出ないようにする。


他の例）実装における工夫

例）管理画面からデータを一括アップロードしたい普通のCSVだとカラムの並び順などで処理してしまうが。。

考）ヘッダーにマッピングのカラム名が入っていればよい。機能の増減もあるので、４カラム５カラム、データ入稿で好きな使い方をできるようにする。

製品のライフサイクル＝ECは数年と長いライフサイクルを踏まえ、どういう設計にするかプロダクトの寿命を考えると柔軟性が重要。


マルチテナントと製品寿命

マルチテナントと製品寿命が長いのを考慮して作る何を解決する仕事と思っているかが大事。SIの解決方法とは大きく異なる。

サービスは規模によって、今後の方法論を変えていかなければならない。今のテナント数だとよくても、物理とかIOとかにぶつかる方法論を使っていたりもする。コストを下げるため、集約するほど問題になっていく。※これらテナント数の問題については事前に見えている


マネージドサービス組み合わせのコスト感

各サービス数ドル程度からの利用で人手のかからない強固なインフラが構成できる。結果、低コストで人手が少ないと、サービス価格を落とし、競争力を高めることができる。

Other Service

数十ドル数十ドル数十ドル


工夫＝リソース用CDNの価格を抑える

例えばKeyCDNはCloudfrontの半額


BizSparkという最高のスタートアップ支援

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


予定＝コンピューティングの仕入れ値を下げる

AzureのPre-Purchaseプランを活用予定1年分事前払いで最大63%引き


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案件くらい


PaaS＋マネージドサービスで楽して迅速に

シンプルな構成、極力複雑さを避ける

コンピューティング(PaaS)

WebApps(サービス、管理者サイト、ジョブ)

Microsoft Azure データセンター

ストレージ

Blob静的ファイル配置、他CSVなど

マネージドサービス

永続化領域(データベース、ログ)

Git Hub等からのデプロイ

SQLDatabase

Redisキャッシュ

モニタリング

Express Route

外部接続

マーケットプレイス

Blob

オンプレミス


課題管理、コミュニケーション


クラウドデザインパターンは重要

MSのデザインパターン＝設計、実装寄りAzure CloudDesignPattern 検索

AWSのデザインパターンとは違う切り口クラウド上での汎用的な設計と実装※アーキテクト、実装者は読んだほうがよい良書。

※英ドキュメントは無償※JAZUGコミュニティで翻訳出版


デザインパターンの運用ケーススタディ

■最近あったことEX）１か月で50万人が登録するアプリ(秒間＝100)が

リリース後、30分で50万人登録するアプリに変貌。秒間＝数千に。→どうするか？


クラウドデザインパターンの知見を使う

50万人30分に耐えるように再設計、改修(約半日で)Asynchronous Messaging Primer・RDBへのINSERTがボトルネックに、非同期に

Cache Aside・RDBへのREADがボトルネックに、Cacheに退避


50万人30分のコスト感

・RedisCacheの月２万円分・Queueの数十円分


SIでクラウドに携わる際考えていること

サービスで収益や成果を上げないとビジネスが続かない。ただでさえ、すんなりとはうまくいかない新規事業が多い。

速度を優先する。成果を上げるために、実装したビジネスの結果を極力早く知る。すべての機能を実装する前にリリースも提案する。

ロジックとビジネスに注力して、シンプルに、楽に運用する必要がある。その後、しがらみなく、改善を続けていきたい。※技術と体制(ビジネス)のしがらみは常に改善


SIerとしての進化？

コンピューティング、バッチ、SQLDatabase、ストレージ、キャッシュ、メール(SendGrid)マネージドサービスで毎回ほぼ足りるつまり、シンプルな構成にすることが大事

PaaS+マネージドサービスだと一人のエンジニアがDevとOpps両方できる。

これはSIerとしての進化だと考えている。


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


マネージドサービスは便利であるが懸念も

構築時に存在していない機能、マネージドサービスがあるので、構成したタイミングによって構成、設定が微妙に異なる。※技術的負債になるケースもある。

A案件＝CloudService(旧型のPaaS)B案件＝WebApps(2013年の機能)+Cache(Roleベース)C案件＝WebApps(2015年の機能)+RedisCache

保守するエンジニアでも最新情報のキャッチアップと設計や設定を見直す力が必要。※情報の共有も


最新の機能を熟知する

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


ディスコン発生時

■ディスコン発生時の費用より良いサービスが出た場合、乗り換えが可能だったり、ディスコンとなるサービスも存在する。後あと回避できない状況が発生することもある。

が、目に見えない、顧客への変化が出にくいケースでは、費用を確保しにくい。

一般的に別の手段が提供されるので大きな心配は不要だが、マネージドの弊害として予め伝えておく必要がある。


アプリケーション保守について

「楽なんでしょ？」保守費を減らしたいという顧客も。従来と同じお金(保守＝高利益)の考え方ではいけない。

ネットコマース株式会社最新のITトレンドとビジネス戦略/2015年10月版/ビジネス編

■顧客への還元◇ノウハウの還元・最新の情報を知り良いものを提案◇コストの還元・PaaSの方を安くする・工数積算からの脱却


ノウハウ還元＝最新情報の検証、提案

新しいもの、特にコストや手間を補う便利なものは積極的に試して提案する。情報はチームで共有して提案していく。

SQLDataWarehousePowerBIの話など。※BIが廉価に。


コスト還元(PaaS + Managed)

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

Copyright ©2015 Sigma Consulting All Rights Reserved. confidential51

悩み＝工数積算の限界

月額で１万円は安くなる実装があるが実装に数日はかかり20万円ほどのコスト

やるべきか。回収には２年かかる。

後の顧客でスケールすることであればやるべき?今の顧客でもらえないなら、やらない?→工数積算型の考え方では成立しない

Copyright ©2015 Sigma Consulting All Rights Reserved. confidential52

悩み＝工数積算の限界２

先ほどの30分50万人対応知見とクラウドデザインパターンで解決。誰にもできることではない。

いくらもらうべき?→工数積算型の考え方では成立しない


我々はポストSIの世界に来ている

クラウドの効果的な運用はポストSIビジネスの世界では工数積算から離れた考え方が必要

ネットコマース株式会社最新のITトレンドとビジネス戦略/2015年10月版/ビジネス編

スモールかつ迅速なスタートであれば収益構造の検証を行いやすい・サブスクリプション・レベニューシェア・成果報酬


SIerとお金、工数積算からの脱却

クラウド運用の世界、工数積算から脱却するSIerはお金のもらい方を見直すチャンスにあるお金のもらい方は哲学(文化)に影響する。

・納品しない開発・レベニューシェア・成果報酬シグマではクラウドを背景に色々試した。良くも悪くも色々な経験があるので、まとめ中。後日。


オマケ）MPNを活用した売上

Microsoft Partner Network顧客のAzure消費費用からキックバックを受ける


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

56

Copyright ©2015 Commerble All Rights Reserved. confidential58

運用ツール(監視と連絡が中心)

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


文化(哲学)

Azureの未来につながることであれば何でも叶える努力をする。

・情報発信の大切さ・新サービス、新要求の検証、追及→Azureでは、日本ではまだ…を叶える

・知見から、約束できないことを断る→オススメできない構成の却下


問題＝啓蒙が足りない

顧客からの問い合わせ「Azureがおかしい」「Azureか顧客マターか、その中間か？」→切り分けが重要

アプリケーションがおかしい→顧客マターを減らすためには啓蒙が必要


Azure自体の啓蒙が事業に不可欠なので

Microsoftと共同で自習書を作りました※Azure 自習書で検索。


日本DC稼働時の検証テストでバグを多数報告

日本のユーザーが安心して使えるよう様々なケースをテスト


Azureサポートの方との関係は非常に大事

問い合わせ時点での信頼関係が違う適宜フィードバックを送りましょう


顧客要望を哲学とAzure愛で叶え続ける

MSPでは、メニューは開発され続ける※DBの業務固有なメトリクス通知など

複雑怪奇な要望＝叶えると売上は大きいが…＝哲学とAzure愛に従うべき


自戒）オンプレの不幸をクラウドに持ち込むな

MSPお金を稼ぐのは大事。だが、オンプレの不幸をクラウドに持ち込んではいけない。

●ダメMSPな行為複雑にする＝売上増える仮想マシン構築の金額で数十万＝自動化する能力がない複雑にして管理しないインフラでいいのか＝管理するポイントがわかっていないマネージドサービス作成１クリック５万円＝適切なお金か？


手短にクラウド運用まとめ

・ツールは手段であり目的でない。ビジネスと文化(哲学)の結果。

・哲学はクラウド運用では不可欠。

・これらの検討過程はコンテキストで異なる。自分の立場でよくよく考えてみよう。

Technology

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