ERP のクラウドシフトが進むらしい [cloudpack OSAKA blog]
ナスです。
こんなニュースが流れてきました。 www.e-logit.com
クラウド ERP ってなんだろう？？？
言葉の定義がよくわからないのでモヤモヤします。実際にニュースの終わりの方に「本調査では詳細な定義は示さず、「クラウドERP」としてイメージされるものについて回答を募っています。」とあります。こう言う文言からも、まだ日本人にとってクラウドというものはよくわからない存在なんだなって思わせられます。
IaaS に ERP システムを載せることなのか、SaaS の ERP を利用することなのか、それとも他の何かなのか、それ次第でこのニュースから伝わる内容が変わってきますが、面白い内容なのでちょっと見てみましょう。
5 年後にはかなり ERP システムをクラウドで使う見込み
クラウドの仕事に携わる身としては嬉しいですね。実際にシフトが進むかどうかは置いといて、現在そのように考えられている会社が多くなってきたのがいい流れだと思います。 ERP システムはパフォーマンス(応答速度)が比較的重要視されます。IaaS 環境だと仮想マシンの性能を選べるので、今のスペックでは要件を満たせないと判断すれば一つ上のスペックを選び直すだけで改善できる環境になるので、オンプレミス環境でパフォーマンスに悩んでいる会社さんほどクラウドを検討して欲しいと思います。
さらに開発や検証といった環境は、使わない時は停止することで費用を安く抑えることができます(IaaS の場合)ので、本番環境以外だけでもクラウドに持ってくる意味はあると思います。
ちょっと気になるのが、SaaS 移行する場合ですね。日本の場合は、アドオンと呼ばれる機能追加プログラムを多数作って業務を回している会社さんが多いです。そんな環境を SaaS 移行するとなった場合にどうなるのか、ちょっと今は想像できないですね。
やっぱりコストは期待される
図 2 に期待と懸念のグラフがありますが、やはりコストは期待されますね。先ほどの SaaS 移行を考えると、業務フローも変える必要が出てくると思いますので、そう考えるとこのアンケートでの「クラウド ERP」はやっぱり IaaS で ERP システムを利用することのように思えます。でも、うーん、わかんない。
ただ、IaaS に移行したからといって必ずコスト削減できるとは限りません。利用するクラウドの特性を良く理解して、うまく使いこなすことで初めて費用対効果が出てきますので、IT 部門の方は単純に載せればいいや、ではなくて色々と調べたり試したりしてほしいと思います。
クラウドのセキュリティについての認識が変わってきた？
ちょっと前だと「クラウドはセキュリティが心配」とは良く聞きましたが、図 2 を見る限り、最近はそうでもないのかもしれません。（まだまだ多いですけどね。）いろんなクラウドの会社が、セキュリティについては説明を何度も何度もしてきているので、それが浸透し始めたのかもしれません。完全に主観ですが、セキュリティが懸念の 1 位じゃないのあまり見ないので引っかかりました。って書いてて、やっぱあまり変わってないかも、とも思えてきた…
ちょっと気になったサービスの存続性
サービスの存続性への懸念が 34.7% ありますね。確かに、移行した先のサービスが突然「終了しまーす」ってなっても困りますからね。ただ、オンプレミスでも同じことは言えるわけで、今後サーバの生産が終了したり、サポートが終了したりすることも可能性は 0 ではないです。なので、今使っている、または今後使おうとしているサービスがなくなったとしても、業務を継続できるプランを考えておく必要はあるのかもしれませんね。
そのプラン内容も色々考えられますね。異なるクラウド環境でも動くシステムにする、オンプレミスとクラウドをうまく使い分ける、クラウドに完全移行するけど何かあったらすぐに移行できる手段を準備しておく (DR 対策に近い？) など、まぁ今は実現可能性は低いかもしれませんが、将来このあたりをサポートするサービスやツールが出てくるかもしれません。しっかりアンテナを張っておきましょう。
今では、IaaS に ERP システムを移行する事例も多くなってきました。これからも、IaaS とか SaaS とかにかかわらず、クラウドに移行したいという話が出てくると思いますので、「AWS に移行するならお手伝いしますよ！」とお伝えしてこの感想文を締めくくりたいと思います。
スケーリングポリシーの動きを確かめてみた [cloudpack OSAKA blog]
ナスです。
Auto Scaling のスケーリングポリシーを見ると、ステップで何段階かに分けて設定できることを知ったので、とりあえずやってみました。
設定してみたスケーリングポリシー
Auto Scaling Group の CPU 負荷が60〜80%未満なら1台追加する、80%以上なら2台追加する、という内容です。また CPU 負荷が 10% 以下になったら 1 台削除する、という内容です。
まずは EC2 インスタンスに stress コマンドで CPU 負荷を 99% くらいにする
最初は EC2 インスタンスを 1 台の状態で開始したので、当然アラームに引っかかります。結果どうなったかというと、2 台一気に増えました。
スケーリングポリシーでステップと書かれていますが、実際にはただの if 文だと思った方がいいですね。
stress プロセスを止めました
これで CPU 負荷が 10% 以下になります。どうなったかというと、1 台削除されました。
そのまま放っていると、1 台ずつ EC2 インスタンスが削除されていきました。
まぁこんな感じです。今までのオンプレミスでのサーバ運用の考え方や運用方法でやっていると、本当に AutoScaling で痛い目にあいます。EC2 インスタンスは死んでもいいように設計しましょう。DB は AutoScaling 外に置きましょう。ログも CloudWatch Logs に出力しましょう。これで一安心です。
