Aws導入時にまず考える〇〇のこと

© RecoChoku Co.,Ltd. Proprietary and Confidential
株式会社レコチョク
2017/8/31
AWS導入時にまず考える〇〇のこと

自己紹介
22017/8/31
■名前
野村昌男 (Masao.Nomura)
■所属
事業システム部基盤グループ
■お仕事
AWS含めた、商用サービス環境全体基盤の設計と構築と管理
とセキュリティ屋さん
元々はオンプレミスのインフラ屋さん
弊社エンジニアブログで(たまに)書いてます
https://techblog.recochoku.jp/

© RecoChoku Co.,Ltd. Proprietary and Confidential 32017/8/31
■本日のお品書き
前半
・「AWSを使う」とは？
・AWSを使った環境デザインパターン
後半
・レコチョクの場合

「AWSを使う」とは？

52017/8/31
「AWSを使う」という話になった場合、
どういった「サービス(製品)」を使うか
という話が中心になる事が多い

62017/8/31
そもそも
AWSって、どんなタイプのサービス(群)なの？

72017/8/31
AWSって………
IaaS
PaaS
SaaS
どれなのよ？

82017/8/31
AWSは、
IaaSであり、PaaSであり、SaaSでもある
■IaaS
元々はこのタイプとしてスタート
一番柔軟にAWSサービス群を使い倒す事が出来る
■PaaS
提供されているサービスの一部は、PaaSである
S3、RDS、Route53など
■SaaS
サービス拡充が進んでいる
WorkMail、WorkDocs、SES、SNS、SQSなど

92017/8/31
IaaS/SaaS/PaaS それぞれ各種サービスが豊富に揃っているため、
これから、どういう組み合わせや使い方をするかよく分からない
小規模構成な場合や、利用の初期段階は
・お試しで使ってみる
・Try&Errorで試行錯誤する
で問題は無いが……
本格的に、また大規模に利用をする場合は
AWSを
「どう使わせるか」
を考えておく必要がある
後々すごく苦労する事が出てきます(経験則)

102017/8/31
なぜか？

112017/8/31
決めておかないと……
〇AWS環境の使い方の方向性がブレてしまって、
「汚い」環境になってしまう
特に、「AWSを使う事」が決まってしまっている場合はなりがち
運用、管理工数が増大するリスク
・環境の管理をするのか、サービスの管理をするのかが
あいまいになってしまう
・IaaSで想定していたのに、それ以外の使い方(特にPaaS利用)
を始めた場合、接続ポイントやアカウント管理方法を見直す
可能性がある
何でも出来てしまうが故の問題
・自分たちでルールを決めておかなければ、すぐカオス

122017/8/31
〇自分のやってる仕事がよく分からなくなってしまう
皆様の立ち位置にもよるので一概には言えませんが……
自分は開発者？運用管理者？
・責任分界点があいまいになる可能性が大きい
環境を提供するまで？使えるようにするまで？
ルールを決めるまで？
・フルスタックなら良いけど、会社として大丈夫？
自分たちでAWSを使う事を選択しているなら良いが、
大人の事情で使うことが決まっている場合は、
何のために使うのかを一旦整理しておくと良い
これからどう使うか、
を考える前に、
どうみんなに使わせるか(使ってもらうか)を考えておく事
が大事

AWSを使った環境デザインパターン

VPCを使う
142017/8/31
大前提として……全てのパターン実装において、
AWS環境はVPCを基盤として考える
※サーバレス環境しか考えてない場合は必ずとは言えない
VPCを利用しないAWS環境を利用し始めてしまった場合……
ある程度の規模の環境になった段階で、まず間違いなく破綻する
Amazon VPC

VPCを使う
152017/8/31
VPCとは、
無秩序なAWS空間に秩序をもたらす仕組み
例えるなら……

VPCを使う
162017/8/31
例えるなら…
■VPC無し
DCの床の上に、ONUからL2SWを一つかまして、
とりあえずサーバを並べて、空いてた電源から通電させて、
それぞれにOSやらパッケージぶち込んでサービス提供！
※とりあえずある分から置いていくイメージ
■VPC有り
事前に論理設計と物理設計した
DC内のラックに、サーバを計画的に
設置し、アクセスコントロールを
FWで行いつつサービス提供！

VPCを使う
172017/8/31
例えが少し乱暴でしたが……
VPC上でなければ実現できない設計上の仕様が多い
・IPアドレスレンジの設定
・サブネットの作成
・ネットワークルーティングの設定
・マネージドのVPNエンドポイント
⇒SoftwareVPNであればその限りでない
エンタープライズ環境で考えた場合、
VPCを使わないAWS環境設計はあり得ない
と思われる

AWSを使った環境デザインパターン
182017/8/31
AWSを利用した環境パターンは大きく3つ
1.AWSだけで環境を構築する
ex) 既存環境をAWSへ全面移行
新しく環境をAWS上だけで構築する
2.AWSを既存環境に追加する
2-a.既存オンプレミス環境にAWSを追加
2-b.既存他クラウドサービスにAWSを追加
ex) GCP + AWS, Azure + AWS .etc
※オンプレミス + 他クラウドサービス + AWSは
上記2(a+b)の複合パターンとなるため割愛
+
+
+ +

AWSだけで環境を構築する

202017/8/31
3パターンの中では一番気楽
とはいえ、考えなければいけない事は一番多いかも
■良い所
自由度が高い
■注意しておくこと
・AWS上で動作しないソフトウェアの有無
⇒ソフトウェアアプライアンス系に見られる
・提供されるサービスのパフォーマンス等、要件を満たさない場合の
代替案を考える必要性
・AWSの可用性が全て
⇒AWSが使えなくなると終わる

212017/8/31
環境検討時の勘所(レコチョク経験則)
・デフォルトVPCは使うな
⇒ただし消さない事……消すと色々面倒な事に
・IPアドレスの設計は余裕を持って
⇒ガチガチにすると、拡張性が無くなる
・ルーティングは簡単に
⇒障害時など、経路が複雑になればなるほど調査が面倒
※AWS側は基本的にログが出てこない

AWSを既存環境に追加する
既存オンプレミス環境にAWSを追加

232017/8/31
実は一番多いパターンかと思われる
AWSへ全面移行するにしても、このパターンは並行稼働中に利用する
■良い所
追加する環境は、準備期間含め、稼働開始までが圧倒的に早く出来る
逆に撤去(削除)も早く済む
・既存環境とAWS環境のIPアドレス設計思想の差異
⇒DHCP基本、サービスによって最低限必要なIPアドレス数がある .etc
・ネットワーク帯域の差異
⇒AWS側はEC2インスタンスタイプに依存する
・ルーティング設計
⇒複雑にしないためには、エンドポイントをどうするかが悩ましい
・AWS固有の問題

242017/8/31
AWS固有の問題(仕様)
レコチョクでは「2hop問題」と呼んでいる
VPC Peering(VPC間をマネージドでVPN接続してくれるサービス)、VPN、DirectConnect
を経由した通信時、2拠点を超えたルーティングが実装出来ない
0-hop
1-hop
2-hop
3-hop
0-hop
3-hop
1-hop
2-hop
Edge-VPC
HUB-VPC
参考
http://aws.typepad.com/sajp/2014/04/vpc-peering-tips.html
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-amazon-vpc-47025202

252017/8/31
・IPアドレス帯域は、分かりやすく分けてしまう
⇒パッと見て環境が判別できるレベルにする
・データ転送経路を考慮した、ネットワーク帯域を考える
⇒フロントがAWS、バックがオンプレなどの場合意外とハマる
・環境間接続ポイントはシンプルに
⇒接続ポイントを増やすと、アクセスコントロールが面倒

AWSを既存環境に追加する
既存他クラウドサービスにAWSを追加

272017/8/31
このパターンは今後増えると思われる
今は無くても、想定されるパターン
■良い所
各クラウドサービスの良いとこ取りが出来る
・既存環境とAWS環境のIPアドレス設計思想の差異
⇒各クラウドサービスによって実装思想が異なる可能性がある
・クラウド環境間のVPN接続はマネージドで提供されていない
⇒自分たちで実装するしかないので、
可用性などは自分たちで決める必要がある
・AWS固有の問題
⇒先の「2hop問題」に注意

282017/8/31
・管理体系が大きく異なるので、事前に確認しておく
⇒AWSで出来て他クラウドサービスで出来ない事、などがある
・経路間接続の実装方法
⇒マネージドサービスで出来ない事、仕様上出来ない事を理解する

レコチョクの場合

302017/8/31
2013年
オンプレミス環境から、AWS環境への本格移行を開始
レコチョクでは、v1環境と呼んでいる(理由は後述)
インフラ観点で考えたこと
・既存オンプレミス環境との差異を出来る限り無くす
環境面
IPアドレス設計思想は既存環境と同じ
運用面
インフラ担当者による集中管理

312017/8/31
苦労したこと、悩んだこと
・クラウド移行したら仕事が増えた
オンプレと同じ運用管理体制 + 増え続ける新規サービス
⇒ オンプレと同じ役割分担だと大変になる
・ログが集まらない
障害時の調査は、基本自分達で取れるログだけが全て
⇒ サポートはダメもとでも聞いてみる
・思ったよりパフォーマンス問題で悩まされる
可用性とコストとの兼ね合いになるが、要件を再度見直すなど
⇒ 今ある要件は、絶対必要か？

322017/8/31
2015年～
AWS環境の利用の仕方を見直し、
新しい利用方法に沿ったAWS環境を再設計、再移行
レコチョクでは現在のこの環境を、v2環境と呼んでいた
※現在は完全移行したのでこれしかない
インフラ観点で考えたこと
・クラウド環境を使うにあたって最適な設計
・DevOpsにマッチした責任分界点の設定
・インフラに詳しく無い担当者でも分かりやすい設計

332017/8/31
苦労したこと、悩んだこと
・役割は明確になったが、運用ルールが増え続ける
とはいえガイドラインはしっかり作っておく必要がある
⇒ ガイドラインとチェック機構がしっかりしていればOK
・全体の品質管理を考える仕組み作り
システム全体を「見える化」する取り組み
⇒ やり方は色々あるので試行錯誤
・増え続けるサービスとの闘い
結局は新サービスが出る度に「どう使わせるか？」が続く
⇒ こればっかりは仕方が無い

342017/8/31
そして現在………

まとめ

まとめ
362017/8/31
■「AWSを使う」とは？
サービスをどう使うかが注目されがちだが、
インフラ目線で考えた時、どう使わせるか
を考えた設計をしておかないと、後で絶対苦労する
IPアドレス設計、拡張性、万が一の際の代替手段 .etc
■AWSを利用した環境パターン
AWSのみ、オンプレミスとAWS、他クラウドサービスとAWS
どのパターンでも、VPCは絶対使う
環境が複数になる際は、
・接続ポイントに注意(エンドポイントはシンプルに)
・ネットワーク帯域に注意(特にローカル通信)

本日はありがとうございました！！
ご質問やもう少し掘り下げて聞きたい事などありましたら、
この後の時間でお声かけ下さい！！

Aws導入時にまず考える〇〇のこと

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Aws導入時にまず考える〇〇のこと

Similar to Aws導入時にまず考える〇〇のこと (20)

More from recotech

More from recotech (10)

Recently uploaded

Recently uploaded (9)

Aws導入時にまず考える〇〇のこと