bluemixでdev opsして分かったpaasの良いとこ悪いとこ
TRANSCRIPT
BluemixでDevOpsして分かったPaaSの良いとこ悪いとこ
自己紹介
• 名前:原田 一樹 (所属: 某商社系SIer)
• BMXUG Community Managerの一人
• 仕事:サービス企画/クラウド技術実証/アジャイル開発
• 好きなBluemixサービス:Node.js、MongoLab、SendGrid
• 保有スキル
o AWS: Solutions Architect - Professional
o AWS: SysOps / Developer - Associate
o Azure: Implementing Microsoft Azure Infrastructure Solutions
o Bluemix: 資格準備中(?)
Bluemixで開発したアプリ(1/2)〜Bluemixハッカソン最優秀賞作品〜
• IAI SLASH 〜すれ違い様に「居合い」でクーポン発行アプリ〜
Bluemixで開発したアプリ(2/2)〜Bluemix Challenge 2015応募作品〜
• またたび 〜対話型旅行プラン提案bot〜
Question and Answer
Auto-Scaling
Monitoring andAnalytics
SendGrid
Virtual machine
負荷テスト
連携クラウド
Object Storage
Machine Learning
観光データ
ユーザーデータ
ヒアリングデータ
評価データ
観光地の画像データを
Public化
ObjectStorage
メール配信
Watson QA
性能監視
スケーリング
ユーザ管理/チャット管理/観光データ管理
チャット履歴データ
MongoLab
予測評価値を付与
CSVファイルの転送
ユーザ評価データCSVエクスポート/
インポート
TravelCorpus
SDKNode.js
乗り換えAPI
Git/Build&Deploy/Track & Plan
【本題】 PaaSの良いとこ?悪いとこ?
よく見るやつ
IaaSはOSからアプリまで全ての設定を行う=手間が掛かる
PaaSは開発するアプリに集中できる。トータルコストが
IaaSより安価
IaaS
開発するアプリ
データベース
ランタイム
OS
サーバ・ストレージ・ネットワーク
PaaS
開発するアプリ
データベース
ランタイム
OS
サーバ・ストレージ・ネットワーク
つまりPaaSは・・・
「開発準備が早い」
「運用の手間が少ない」
「効率化されているからコスト安」
良いことづくめだしPaaS一択なのでは?
つまりPaaSは・・・
「開発準備が早い」
「運用の手間が少ない」
「効率化されているからコスト安」
良いことづくめだしPaaS一択なのでは?
「No」
PaaSを触ったことがある人?
PaaSでアプリを本番稼動させている人?
PaaSの三大挫折ポイント(個人の見解)
1.PaaS独特の手間がある (PaaSがよく分からない)
2.自由度がなくて要件に合わない
3.ブラックボックス領域がIaaSより多くて不安
PaaSの三大挫折ポイント(個人の見解)
1.PaaS独特の手間がある (PaaSがよく分からない)
2.自由度がなくて要件に合わない
3.ブラックボックス領域がIaaSより多くて不安
どれかに該当し挫折すると…
「いらっしゃーい」
PaaSの三大挫折ポイント(個人の見解)
1.PaaS独特の手間がある (PaaSがよく分からない)Ø CloudFoundryコマンドによる操作Ø クライアント開発環境との動作の違いØ ログの取得・保管方法 …など
2.自由度がなくて要件に合わないØ 性能向上のためのチューニングØ 可用性向上のための監視、復旧、冗長の仕組みØ データ保全性向上のためのバックアップの仕組みØ 機密性向上のためのセキュリティ関連の仕組み
3.ブラックボックス領域がIaaSより多くて不安Ø サーバ、ストレージに加え、OS領域が見えないØ トラブル時にOSに手を加えられなくて大丈夫なの?
■PaaSの良いとこ・PaaSは他社が作ったベストプラクティスの固まり
■PaaSの悪いとこ・PaaSは他社が作ったベストプラクティスの固まり
■PaaSの良いとこ・PaaSは他社が作ったベストプラクティスの固まり
⇒使いこなすとメリットが大きい(早い・安い・旨い)
■PaaSの悪いとこ・PaaSは他社が作ったベストプラクティスの固まり ⇒カスタマイズしづらい不安さ (何かあったときどうするの?と、漠然と不安になる)
「使いこなす」 or 「挫折する」
Bluemixの、
“構成技術要素”と
“挫折ポイント”を押さえて
Bluemixを「使いこなす」
POINT
Bluemix構成技術要素
参考元:http://www.slideshare.net/ngaur/bluemix-digital-innovationplatform
Bluemix構成技術要素
参考元:http://www.slideshare.net/ngaur/bluemix-digital-innovationplatform
個別要件はOpenStackやDockerで対応可能
開発環境、利用ツールを選定・ルール化する
共有型、専有型、ローカル型を適宜使い分ける
必要な機能は用意されたサービスを第一に利用検討
経験したBluemix挫折ポイント(5選)
1.ユーザーの操作ログが取れない
2.各サービスのドキュメントが不足
3.Node.jsのライブコーディングの不具合
4.Node.js自体の監視の実装
5.IBM DevOps Service(IDS)のメンテナンス問題
※他にも色々ありましたが今回はこの5つを説明します
1.ユーザーの操作ログが取れない
• Bluemix Public版はポータルにアクセスしたユーザの操作ログが取れない
• セキュリティ監査時にログを求められたときどうする?
Bluemix Dedicated(専有型)を利用すれば、ログ取得・管理が可能(?)
※未検証です。知っている方、ご教示ください。
【Bluemix(Dedicated)説明文引用】
Bluemix (Dedicated) では、管理コンソールを通じて、DataPower®、ファイアウォール、ログイン監査など、ご使用の専用インスタンスのセキュリティーに関するレポートやログにアクセスします。
2.各サービスのドキュメントが不足
• 各サービスの概要レベルのドキュメントは一通り揃っているが、具体的な実装の際の仕様書レベルの情報が不足(2015年8月時点)
(Watson QA、Object Storage、外部(MongoLab、SendGrid)…等)
ü Bluemixチュートリアルから似たアプリがないか探しコードを読み解くØ http://www.ibm.com/developerworks/jp/bluemix/tutorial.html
ü 情報がない場合は技術ブログなどを探すü 外部サービスは各サービス単体の情報を探しBluemix流に改良するü IBM Developer Works 日本語版やユーザー会に質問を投げてみる
Ø https://www.ibm.com/developerworks/community/groups/community/bluemix-jp/
ü Bluemix Developers CommunityのQAに似たような質問がないか探してみるü ない場合は勇気を出して英語で質問を投げてみる
Ø https://developer.ibm.com/answers/smartspace/bluemix/
ü あとはひたすらテスト&デプロイ、テスト&デプロイ・・・で試行錯誤ü 気づきをQiitaなどに投稿し同じ犠牲者が生まれないように貢献する
3.Node.jsのライブコーディングの不具合
• Node.jsアプリはDevOpsサービスのWeb IDEを使うと、ビルド&デプロイなしにBluemix上の環境に変更を加えることが可能
• デバッグ・ツールを使えばNode.js(サーバサイド)のコンソールを表示させることが可能
⇒ローカルに開発環境作らずにエラー内容も確認しつつ、リアルタイムに開発できるのでは?
ü Node.jsへ様々なモジュールを追加し、コード数も増えてきたあたりでライブコーディングの同期が取れなくなった(2015年8月時点)
ü デバッグ・ツールのエラーコンソール機能がすぐに切断されてコンソール表示されないようになった。
⇒クラウドのみでの開発を諦め、ローカルに開発環境を用意
残念ながら…
【参考】 Node.js ライブコーディング(1/2)デバッグ・ツール
ボタン
デバッグ用のコンソール画面を表示
左記画面が表示される(要:IBM ID と PW)
【参考】 Node.js ライブコーディング(2/2)
数分経過すると…
ローカル環境と同様に、Console.logの内容を確認できる
数分経つと接続が切れてしまうため、都度リロードして再接
続する必要あり
4.Node.js自体の監視• Bluemixは、「Health Manager」という機能でインスタンス単位の監
視・復旧を実装済のためユーザー側は意識する必要なし• ただし、アプリケーションレベルの監視についてはユーザー側で対応
が必要• Node.jsはエラー時にインスタンスは停止しないがNode.js自体が停
止する現象はよく起きるが、「Health Manager」や「Ping監視」などでは異常に気付くことができない。
• Node.jsのモジュールにforeverモジュールを追加し、Bluemix上で起動する際のスタートコマンドを書き換えることで、Node.js自体の監視・自動復旧する機能を実装可能。
• Package.jsonの 「scripts」と 「dependencies」 に変更を加えてビルド&デプロイするだけで実装可能。
【参考】 package.jsonの書き換え
"scripts": {
“start”: “node app.js"
},
"dependencies": {
//必要なモジュールを記載
},
"scripts": {
"start": "./node_modules/forever/bin/forever app.js"
},
"dependencies": {
"forever": "0.14.2",
"utile": "~0.2.1",
"nconf": "~0.6.9",
"colors": "~0.6.2"
},
■ 通常のNode.js on Bluemix ■ foreverモジュールを組み込んで動作させる場合
Node.js自体のエラー時にインスタンスは稼働しているが、Node.jsが動作しない状態に
Node.js自体がエラーで停止した際に自身で停止を感知し、停止から数秒で再稼働する状態
5.IDSのメンテナンス問題
• IBM DevOps Serviceは、Git機能、Web IDE、ビルド&デプロイ機能などを兼ね備えた非常に便利な開発支援サービス
• 但し、メンテナンスが多く、Git使えない時間帯やデプロイできない時間帯が発生してしまうため、メンテナンス時間をしっかりと把握しておく必要がある。
■IBM Bluemix DevOps Services statushttps://status.hub.jazz.net/
■Maintenance Schedulehttps://developer.ibm.com/devops-services/support/#maintenance
5.IDSのメンテナンス問題
• 2、3日に1回のペース
• メンテナンス中は各機能が利用不可。
(Git、デプロイ、Web IDE…)
• リージョン共通サービスのため、日本時間の考慮はなく、平日のオンタイムでのメンテナンスも多い
• IBM様、改善を期待していますm(_ _)m
■Maintenance Schedule
まとめ
• PaaSの良いとこは、
「開発準備が早い」 「運用の手間が少ない」 「効率化されているからコスト安」
• PaaSの悪いとこは、ベストプラクティスを強制するため、慣れるまでにいくつもの挫折ポイントが多くある(特に個別対応好きの日本の文化は尚更)
• 挫折ポイントを乗り越えて使いこなしたときには、IaaSでは得られなかったメリットを多く享受できる
• みんなで協力して挫折ポイントを潰していき幸せなPaaSライフを築き上げましょう!!
• そしてBMXUGも盛り上げましょう!!
http://softlayer-bluemix-summit.jp/
SoftLayer Bluemix Summit 2015
SoftLayer Bluemix Summit 2015
Track B15:30~16:00
PaaSを使いこなす!!「インフラSIer」の進化
【講演者】 小岩井
Track D16:30~17:00
WatsonQA応用編〜独自corpusを作成しBluemixと連携させる方法〜
【講演者】 原田
■セッション情報