D-2
Ⓒ 2016 Classmethod, Inc.
Developers.IO 2016
城内秀仁 シニアソリューションアーキテクト
クラスメソッド株式会社
2016年02月20日
AWSで生まれ変わる新しいエンタープライズシステムの理想と現実
#cmdevio2016 #D
D-2
Ⓒ 2016 Classmethod, Inc. 2
アジェンダ
1. 自己紹介
2. AWSには
3. エンタープライズシステムの移行プロセス
4. AWS利用の障壁
5. AWSに求めるもの、AWSから得られるもの
6. まとめ
7. 質疑応答
D-2
Ⓒ 2016 Classmethod, Inc. 4
1. 自己紹介
• 名前は... 城内 秀仁(きうち ひでとよ)
• 経歴は... ずっとインフラエンジニア(サーバ)
• 業界歴は... 11年目
• AWS歴は... 2年半くらい
• 主な仕事... エンタープライズ企業様向けコンサル
SAYAKA ISOさんにデザインしてもらいました
D-2
Ⓒ 2016 Classmethod, Inc. 6
2. AWSには
AWSとは、Amazon Web Servicesの略称で、Amazon.
comによって提供されるクラウドコンピューティング
サービスです。
D-2
Ⓒ 2016 Classmethod, Inc. 7
2. AWSには
AWSが提供しているサービスの数は約50くらいです
(2月20日時点)。最近のまとまったアップデートとし
ては、昨年のre:Invent 2015で発表された新サービス
や機能追加が約30くらいありました。
マネージメントコンソールの画面にアイコンがぐっちゃり。。
D-2
Ⓒ 2016 Classmethod, Inc. 8
2. AWSには
AWSは、次々に新しいサービスをリリースし、また、
既存のサービスに関しても改善や機能追加を行ってい
ます。
Q: 皆さんは、このスピードについていけていますか?
A: YES or NO
D-2
Ⓒ 2016 Classmethod, Inc. 9
2. AWSには
主観ですが、ついていけないのが普通だと思います。
そこを敢えて追いかける技術者(変人*1)たちがこちら
です。
*1 クラスメソッド社内では、「変人」は褒め言葉です。
Developers.IO
D-2
Ⓒ 2016 Classmethod, Inc. 10
2. AWSには
AWSには、弊社のようなAWS専業ベンダーがいます。
なぜかというと、AWSがそれだけ巨大で深化したプ
ラットフォームであるからです。
AWS移行の教訓其の一
AWSの利用を検討する場合は、
まず信頼できるAWS専業ベンダーを選定するべし!
D-2
Ⓒ 2016 Classmethod, Inc. 12
3. エンタープライズシステムの移行プロセス
AWSマイグレーションに関する情報はすでに数多く公
開されており、弊社のブログでもまとめ記事を掲載し
ています。• オンプレシステムのAWS移行時に参考になる情報まとめ(2015年6
月版)| Developers.IO
本章は、私の経験から見たよくある移行プロセスと、
そのプロセスを実行していく中で、起こり得るあるあ
るネタをご紹介したいと思います。
D-2
Ⓒ 2016 Classmethod, Inc. 13
3. エンタープライズシステムの移行プロセス
私がお客様にコンサルする中でよくあるプロセスは、
おおよそ以下のような2つのパターンに集約されます。
クラウド選定 PoC
実機検証標準設計
ガイドライン作成(標準設計)
環境準備
個別設計 環境準備
システム構築
システム構築
設計先行型
実装先行型
実装先行型:実機検証含めAWSの利用が始まると、なんとなく動作実績が積み上がり、
標準設計が固まる前にAWSへ移行したいと言い出すシステムが出てくる。
設計先行型: AWSの理解が浅く、AWS上でのシステムイメージが掴めない状態で設計を
行うため、どうしても保守的になってしまい、ストレート移行に倒れやす
くなる。
あるある
D-2
Ⓒ 2016 Classmethod, Inc. 14
3. エンタープライズシステムの移行プロセス
先のどちらのパターンにも共通して言えることは、設
計が不十分な状態でシステムを構築することになる、
という点です。
• 実装先行型では、移行したいシステムがリリース期限を切って
しまうため、それに間に合わせるようにスケジュールを調整し
たり、作業を行う必要が出てくる。
• 設計先行型では、そもそもAWSに関する十分な理解がないまま
で設計を行うことになる。また、仮に実際にAWSを触り始めて
理解が深まってきたとしても、そこからの設計のやり直しはで
きない状態であることが多い。
D-2
Ⓒ 2016 Classmethod, Inc. 15
3. エンタープライズシステムの移行プロセス
では、どうすればいいの?という感じかと思いますが、答えはシ
ンプルです。
「設計が不十分な状態でシステムを構築」することを想定に入れる
計画
実装
テスト 設計
AWSでは何度でも構成の追加・変更が可
能です計画
実装
テスト 設計
計画
実装
テスト 設計
AWS移行の教訓其の二
AWSの設計・構築はミニマムから始めて、
サイクルを回しながらブラッシュアップするべし!
D-2
Ⓒ 2016 Classmethod, Inc. 17
4. AWS利用の障壁
本章では、AWSを実際利用してみようとなった段階で
障壁となるポイントをいくつか挙げてみたいと思いま
す。もちろんお客様によっていろいろな障壁があるの
ですが、だいたいのお客様が対峙しなければならない
であろうポイントをご紹介したいと思います。
D-2
Ⓒ 2016 Classmethod, Inc. 18
• インターネットゲートウェイへの警戒感(閉域網前提)、ネットワークACLやセキュリティグループで過剰に制限を設ける
• DXの開設までには数か月かかる(VPNは数日で開設できる)
4. AWS利用の障壁
以下に3つのポイントを挙げます。
ネットワーク
• 既存のソフトウェアがAWSをサポートしていない• パッケージ製品の仕様が理由で、AWSで使える機能に制約が出てしまう(Auto
Scaling未対応、RDS等の外部DBがNG等)
既存のソフトウェア・パッケージ製品
• サーバのスペック等をキッチリ決めてからでないと構築に入れない• リソースの使い捨てに対する抵抗感• エコシステムの利用に対する認識不足
オンプレマインド
D-2
Ⓒ 2016 Classmethod, Inc. 19
4. AWS利用の障壁
以下に先のポイントから得られる教訓を列挙します。
AWS移行の教訓其の三
AWSのネットワークサービスをよく理解し、
過剰な制限をかけないように注意するべし!
AWS移行の教訓其の四
既存のシステムをベースとせず、
AWSの最適な構成をベースに落としどころを探るべし!
D-2
Ⓒ 2016 Classmethod, Inc. 21
5. AWSに求めるもの、AWSから得られるもの
最後は、皆さまにいくつかの問いかけをして終わりに
したいと思います。
ぜひ一緒に考えてみてください。
D-2
Ⓒ 2016 Classmethod, Inc. 22
5. AWSに求めるもの、AWSから得られるもの
AWSを利用することのメリットは多くありますが、何
のためにAWSを利用するのか、明確になっているで
しょうか?
インフラコストを下げたい
システムのアジリティを高めたい
D-2
Ⓒ 2016 Classmethod, Inc. 23
5. AWSに求めるもの、AWSから得られるもの
お客様の多くはコストメリットの評価に対する比重が
大きいと思われます。実際に、オンプレからの移行に
より、ランニングコストが削減できた実績は多くあり
ます。
D-2
Ⓒ 2016 Classmethod, Inc. 24
5. AWSに求めるもの、AWSから得られるもの
ただ、それは本当に「AWSへの移行」である必要があ
るでしょうか?
もしビジネス的な目標を達成するためのコスト削減で
あれば、別の方法(クラウド移行を除く)での削減は
検討されたでしょうか?
クラウドファーストというキーワードやAWSという流
行りが前提となっていませんか?
そのAWS移行が本当にビジネスオリエンテッドであり、その方針に対して最適な手段であるか、もう一度考えてみてください。
D-2
Ⓒ 2016 Classmethod, Inc. 25
5. AWSに求めるもの、AWSから得られるもの
では、一方でシステムのアジリティに関してはどうで
しょうか?
ちゃんと恩恵を受けられるように設計していますか?
AWSはあくまでシステムのパーツを提供しているのであって、システムを提供している訳ではありま
せん。
もしアジリティを求められていないとしても、いまのビジネスの成長スピードに対してシステムがボトルネックになっていることはな
いでしょうか?
D-2
Ⓒ 2016 Classmethod, Inc. 26
5. AWSに求めるもの、AWSから得られるもの
では、最後の教訓です。
AWS移行の教訓其の五
システム要件は常にビジネスオリエンテッドであって、
特定のアプリケーションやプラットフォームを
前提としたものでないことを再確認するべし!
D-2
Ⓒ 2016 Classmethod, Inc. 28
6. まとめ
いままでご紹介した教訓を以下にまとめます。
1. AWSの利用を検討する場合は、まず信頼できるAWS専業ベンダーを選定するべし!
2. AWSの設計・構築はミニマムから始めて、サイクルを回しながらブラッシュアップするべし!
3. AWSのネットワークサービスをよく理解し、過剰な制限をかけないように注意するべし!
4. 既存のシステムをベースとせず、AWSの最適な構成をベースに落としどころを探るべし!
5. システム要件は常にビジネスオリエンテッドであって、特定のアプリケーションやプラットフォームを前提としたものでないことを再確認するべし!
Top Related