Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか

2,960 views

Published on

  • Be the first to comment

AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか

  1. 1. AWSへのWindows Server 2003の移行 そして今後インフラとどう向き合うべきか 2015.7.11 cloudpack 吉田真吾 第5回 JAWS-UG くまもと 勉強会
  2. 2. 自己紹介 ☁ cloudpack エバンジェリスト ソリューションアーキテクト – AWS設計・移行支援 – コンサルティング ☁バックグラウンド – GISシステムや証券システム 基盤の開発を経て 2013.1より現職 ☁AWS SAMURAI 2013
  3. 3. JAWS-UG 熊本支部 第4回勉強会に 参加したんだモン ☁2013/7/31(水) http://yoshidashingo.hatenablog.com/entry/20130802/1375433689
  4. 4. 久しかぶりたい! 2015/7/11(土)
  5. 5. Windows Server 2003のサポート 終了情報 ☁ 2015年7月15日(日本時間)にマイクロソフト社が提供し ているOS「Windows Server 2003」のサポートが終了しま す。OSのサポート終了後は、新たな脆弱性が発見されても修 正プログラムが提供されないため、脆弱性を悪用した攻撃を 受け、「サーバーが乗っ取られる」「業務が停止する」「機 密情報が漏洩する」などの被害に遭う可能性があります。ま た、脆弱性は昨今問題となっている内部不正への悪用も懸念 されるため、企業・組織のリスク回避の観点から、 「Windows Server 2003」を利用するシステムは後継システ ムへの移行が求められます。 出典)Windows Server 2003のサポート終了に伴う注意喚起(IPA) https://www.ipa.go.jp/security/announce/win2003_eos.html
  6. 6. よくある話 ☁ 「わざわざ動いてるものを置き換える意味ってあるっけ」 ☁ 「社外向けのサーバーならまだしも社内のサーバーを頑張っ てリプレイスする意味ってあるっけ」 – ファイルサーバーやActive Directoryなどなど – 脆弱性対策情報データベースJVN iPediaには、「Windows Server 2003」の脆弱性対策情報が2014年度(2014年4月から 2015年3月)49件登録されている。 出典)Windows Server 2003のサポート終了に伴う注意喚起(IPA) https://www.ipa.go.jp/security/announce/win2003_eos.html
  7. 7. 移行計画〜その前に〜 ☁なぜまだ Windows Server 2003 なのか – 作りっぱなしのシステム – 社内の担当者がもういない – IT予算が少ない 2003年 Windows Server 2003 2005年 Windows Server 2003 R2 2008年 Windows Server 2008 2009年 Windows Server 2008 R2 2012年 Windows Server 2012 2013年 Windows Server 2012 R2
  8. 8. AWSへの移行〜バージョンアップ〜 社内体制整備 ☁ 既存システムの有識者 ☁ ネットワークスペシャリスト (社内 or DC → クラウド) ☁ 開発者 見積り ☁ ミドルウェアやアプリ ケーションの改修費用 – 影響調査 – 改修 – テスト ☁ トータルコスト ☁ 品質 ☁ 納期 予算 ☁ ミドルウェアやアプリケー ションの改修費用 – 影響調査 – 改修 – テスト ☁ ランニングコスト概算 ☁ フィットアンドギャップ調査 ☁ PoC ☁ セキュリティ関連 とにかく大変
  9. 9. そのまま乗っけちゃえという 選択肢 時間がない!
  10. 10. AWSへの移行〜2003のまま〜 ☁AWS で Windows Server 2003 が使えます ☁申請要らず★ ★ ★ – 当初は申請フォームが用意されてましたが、方針 変更があり、どなたも利用可能になりました。 – 参考)http://aws.amazon.com/jp/windows/faq/ ☁サポートの考え方 – MSのサポートはない – AWSサポートは「可能な限り稼働が維持できるよ うに努力はするが、あくまで自己責任での利用」 出典)【AWS発表】Windows Server 2003のAmazon Machine Image(AMI) 提供延長に関するご案内 http://aws.typepad.com/aws_japan/2015/02/windows-server-2003_ami.html
  11. 11. AWSへの移行〜2003のまま〜 出典)【AWS発表】Windows Server 2003のAmazon Machine Image(AMI) 提供延長に関するご案内 http://aws.typepad.com/aws_japan/2015/02/windows-server-2003_ami.html
  12. 12. 自己責任でどうぞ くりかえしますが…
  13. 13. AWSはなぜこんなに広まったのか Amazon VPC ☁ ネットワークを自社利用 するときと同じように閉域 なサブネットで区切って利 用できる ☁ VPNや専用線も張れる Amazon EC2 ☁ ほぼ制約のない仮想サー バー – どんなアーキテクチャも、 筋の良し悪しに関わらず 持ち込み可能 Customer Obsession ☁ 顧客要望の素早い実現 ☁ AWSサポートの手厚さ ☁ 放っておけば値下げ API,API,API ☁ APIだけで操作可能 – 大規模環境の運用 – 省力化 Amazon S3 ☁ 容量無制限のオブジェク トストレージ ☁ 圧倒的なSLA JAWS-UG ☁ 開発者同士のネット ワーク
  14. 14. EC2だけでシステムを組むとどうなる? EC2運用コストの中身 ☁ 利用費用 – 通常のWebシステムでは7 割程度がEC2費用と言わ れている ☁ 運用費用 – サーバーの追加構築作業 – パラメータ変更作業費用 – チューニング ☁ 障害対応費用 – サーバーは必ず壊れる 「TCO 70% 削減!」を目指 すなら ☁ マネージドサービスを活用 する – RDS, SQS, ElastiCache, Redshift… ☁ 少ない人数でたくさんのEC2 を運用する – EC2 Auto Recovery – Auto Scaling – CloudFormationや OpsWorksやElastic Beanstalkの利用 (緑色アイコン) – インフラのコード化
  15. 15. オンプレ脳からクラウド脳へ http://www.amazon.co.jp/Amazon-Web-Services-クラウドデザインパターン-設計ガイド/dp/4822211967
  16. 16. AWSクラウドデザインパターン “AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキ テクチャ設計を行う際に発生する、典型的な問題とそれに対す る解決策・設計方法を、分かりやすく分類して、ノウハウとし て利用できるように整理したものである。” 例)Direct Hostingパターン http://aws.clouddesignpattern.org/index.php/CDP:Direct_Hostingパターン
  17. 17. クラウドアーキテクティング原則 出典)クラウドアーキテクティング原則 http://aws.clouddesignpattern.org/index.php/クラウドアーキテクティング原則 ☁できるだけサービスを利用 ☁机上実験よりも実証実験 ☁スモールスタートからスケールアウト ☁変化に対し全レイヤで対処 ☁故障のための設計(Design For Failure) ☁最初だけでなく周期的なカイゼン
  18. 18. Infrastructure as Code ☁コードでインフラを管理する – コードを読めばそのインフラが「どうあるべき か」正しい状態がわかる – バージョン管理できる # -*- mode: ruby -*- # vi: set ft=ruby : hosted_zone ”aws.local." do vpc "ap-northeast-1", "vpc-12345678” vpc "ap-northeast-1", "vpc-abcdefgh” rrset ”hogehoge.aws.local.", "A" do ttl 300 resource_records( "10.0.0.5” ) end 参考)RoadworkerでRoute 53のゾーンを管理する http://yoshidashingo.hatenablog.com/entry/2015/05/19/190613
  19. 19. Code! Code! Code! クラウド環境のコード化 ☁ CloudFormation ☁ AWS CLI ☁ AWS SDK ☁ Codenize.tools ☁ Terraform(HashiCorp) コード管理 ☁ GitHub etc… CI(継続的インテグレーション) ☁ CircleCI, TravisCI, Wercker etc… サーバーのコード化 ☁ Chef, Ansible etc…
  20. 20. コード管理 分散型 バージョン管理システム Pull Request駆動開発 1. 新規ブランチを作成して チェックアウト 2. 空でコミット&プッシュ 3. プルリクエストを作成する 4. 変更をする 5. コミット&プッシュする 6. テストする 7. レビューしてもらう 8. マージしてもらう 9. デプロイする
  21. 21. CI(継続的インテグレーション) CI(ツール/SaaS) ☁ 「コードの静的な状態」→ 「動作環境上で動作している状 態」に必要な機能諸々 ☁ ツールによって、フォーカス する課題と解決のアプローチに 違いがある – CircleCI ­ 幅広いツールと連携した自 動化が可能 ­ オンデマンドなデプロイは 難しい(deployブランチへ のプルリクとか) – Jenkins ­ 運用が面倒… – TravisCI, Wercker etc… – AWS Code Pipeline やること ☁ サーバーのテストやデプロイを行う – 例)GitHubにpushするとCircleCIでビ ルド、配布、Serverspecのテスト実行 ラストワンマイル(自称)問題 ☁ デプロイのルールは千差万別 – 定期的に自動デプロイする – オンデマンドにデプロイ用ブラン チにプルリク – 本番環境から夜間にバッチでPull して引っ張る – 承認用のシステムからJenkinsの ジョブ実行
  22. 22. 出典)クックパッドのデプロイとオートスケール https://speakerdeck.com/mirakui/cookpads-deployment-and-auto-scaling 1日10回デプロイする
  23. 23. 出典)Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイ とはどういうものか? AWS re:Invent基調講演(Day2 AM) http://www.publickey1.jp/blog/12/amazon11000_aws_reinventday2_am.html 1時間に1000回以上デプロイする
  24. 24. 巨人(AWSやSAAS)の肩に乗る 大事なことは… MySQL SSD
  25. 25. システムの業務要件に責任を持つ べき人は誰?
  26. 26. そのために最適な方法はどっちか? 時々大きな予算をかけて移行 プロジェクト ☁ 既存仕様が残ってない 可能性 ☁ 仕様をFIXした時点から ビジネスを取り巻く環境 との差異が広まり始める ☁ リファクタリングなど は除外されがち(動けば よいになりやすい) 毎日小さい変更で継続的イン テグレーション ☁ メンテナンスコストの 最小化・品質担保 ☁ Infrastracture as Code の実践 ☁ ビジネスの要件に素早 く対応 ☁ 日々小さくリファクタ リング可能
  27. 27. DevOps=文化 DevOpsとは ☁ 開発と運用が一体と なってビジネスのゴール に向かう ☁ システムが価値を産む のは運用中 ☁ 日々ビジネスを取り巻 く要求や優先順位は変 わっていく DevOpsのための Infrastracture as Code ☁ ビジネス環境の変化に 備える
  28. 28. エンタープライズに普及する DevOps 文化 参考)日経電子版アプリ内製開発の舞台裏 https://speakerdeck.com/natsuz/ri-jing-dian-zi-ban-apurinei-zhi-kai-fa-falsewu-tai-li
  29. 29. 情報システム担当者が主体的に 持つべき耳の良さ+技術力 耳の良さ ☁ 正しくビジネスのゴー ルを理解する ☁ ゴールまでの技術的な 段取りを理解する ☁ 自分の「少なく・偏っ た」経験で曲解しない – 無知の姿勢 技術力 ☁ 作らない技術 – APIやライブラリ、サー ビスの活用 ☁ 運用しない技術 – 運用が楽になる技術 – コードで運用する ☁ 体系立てて重複も不足 もないドキュメントの整 備
  30. 30. 新しいコラボレーション(協働)スタイル 完全な内製化 ☁ 活発な採用活動 – 著名エンジニアの採用 – 採用費用の確保 – エンジニアに選ばれやす い組織風土作り 内製+アウトソーシング型 ☁ 逆常駐型 – リラックスした職場 – コミュニケーションの密度 – 発注者の社内事情から距離を 取れる、チャレンジしやすい ☁ ワンチームとしての信頼感 – 社内と同じように… ­ 分担できるか ­ 質問できるか ­ 情報共有できるか ­ 褒めあえるか ­ 批判しあえるか ☁ 瑕疵担保責任範囲 内製+スーパーバイザー型 ☁ 特定の言語やツールが得 意な人と契約 – ほぼリモート – そもそも請けてもらえる か
  31. 31. 逆常駐型 出典)世界で展開する新しいネットワークサービス「Miiverse 」のAWS活用事例 Jaws Days 2014 発表資料 https://speakerdeck.com/hatena/jaws-days-2014-miiverse

×