20130831 JAWS Chiba

2,234 views
2,146 views

Published on

2013.08.31 JAWS Chiba #1
Lightning Talk AWS for Ops

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,234
On SlideShare
0
From Embeds
0
Number of Embeds
1,048
Actions
Shares
0
Downloads
7
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

20130831 JAWS Chiba

  1. 1. 保守運用担当からみた AWS JAWS-UG千葉團 Vol.1 「千葉團はじめます。クラウドはじめよう」 classmethod.jp 1 2013/08/31 Kazuki Ueki
  2. 2. 本日の内容 10年間保守運用担当をやってきた 立場からみた AWSでできること できないこと classmethod.jp 2
  3. 3. 自己紹介 名前:植木 和樹(うえき かずき) 年齢:36歳 出身:新潟県妙高市(単身赴任中) 元製造業情報システムG常駐 主にUnixサーバエンジニア(監視、保守) 資格:IPAITサービスマネージャ IPA システムアーキテクト JAWS北陸コアメンバー(JAWS DAYS 2013~) JAWS埼玉コアメンバー(2013年8月~) 好きなAWSサービス:SQS classmethod.jp 3 @czkuk
  4. 4. 本日は 奇抜な事は話しません 話せません classmethod.jp 4
  5. 5. ところで 保守ってなんだろう? 運用ってなんだろう? classmethod.jp 5
  6. 6. 保守 classmethod.jp 6
  7. 7. 日本工業規格 JIS X 0161:2008 classmethod.jp 7 保守の種類 定義 例 改良保守 (ソフト ウェア自体 の修正) 適応保守 引渡し後,変化した又は変化し ている環境において,ソフトウェ ア製品を使用できるように保ち続ける ために実施するソフトウェア製品の修 正。 OS新バージョンへの対 応/消費税対応 完全化保守 引渡し後のソフトウェア製品の潜在的 な障害が,故障として現れる前に,検 出し訂正するための修正。 ドキュメントの改善 UIの改善 (問題への 対応) 是正保守 ソフトウェア製品の引渡し後に発見さ れた問題を訂正するために行う受身の 修正。 不具合の修正 (リアクティブ) 緊急保守 是正保守実施までシステム運用を確保 するための,計画外で一時的な修正。 是正処置実施までの暫 定処置 予防保守 引渡し後のソフトウェア製品の潜在的 な障害が運用障害になる前に発見し, 是正を行うための修正。 ミドルウェアアップ デート、不要ファイル 削除
  8. 8. つまり 「システムが本来あるべき姿」 になるよう対応すること メンテナンス classmethod.jp 8
  9. 9. 運用 classmethod.jp 9
  10. 10. バックアップ 監視 データ収集 定型業務 classmethod.jp 10
  11. 11. 「正常に稼働しているシステム」 を用いて実施する業務 オペレーション classmethod.jp 11
  12. 12. さて classmethod.jp 12
  13. 13. システム構築後のこと 想定できていますか? classmethod.jp 13
  14. 14. 短期間で構築したシステムでも 3年・5年・10年使われる classmethod.jp 14
  15. 15. サービス開始 1ヶ月後 • 当初予想よりパフォーマンスが悪い! • 予想外のCPU負荷、ディスク負荷(焦) • 変なエラーが頻発する(泣) • アプリケーション新機能追加! classmethod.jp 15
  16. 16. AWSなら柔軟に対応できる! • インスタンスタイプ変更 • インスタンス数 追加 • ディスク(EBS)増設 • S3への負荷分散 • CloudWatchによる監視、アラーム • 一時的な検証環境構築 classmethod.jp 16
  17. 17. 【結論】 AWSの柔軟さのおかげで サービス開始後発覚した 「問題」 については かなり上手く対応できる classmethod.jp 17
  18. 18. でも「改良」「運用」はどう? • 複数インスタンスへの同時デプロイ • オートスケーリング用AMIの更新 • メンテナンス用回線、経路の確保 • 稼働ログのチェック • 中長期のリソース利用状況把握 • データベース(RDS)のデータ参照 classmethod.jp 18
  19. 19. サービス開始後の 「運用」 も忘れないでください! classmethod.jp 19
  20. 20. さらに月日が流れ classmethod.jp 20
  21. 21. サービス開始 1年後 • データ領域不足(シャーディング検討) • 新しいAmazon Linux AMIリリース • ミドルウェアのマイナーバージョンアップ • フレームワークのメジャーバージョンアップ • 長期休暇時の連絡体制 • バックアップからのリストア • ドキュメントと実態の乖離 • EC2 instance scheduled for retirement (計画再起動) classmethod.jp 21
  22. 22. サービス開始 3年後 • OSメジャーバージョンアップ 旧世代OSがEOSL(End of Service Life)に • ミドルウェアのメジャーバージョンアップ • フレームワークが次の世代に • 新しいデバイス • データ増加によるパフォーマンス悪化 • 社員の異動・退職 classmethod.jp 22
  23. 23. サービス開始 5年後 • OSが2~3世代くらい古くなる • ライブラリが最新のOSに対応してない • サービス開始時のOSがEOSLに • 当時のISOイメージやRPMが手に入らない • サービス開始当初のメンバはPG定年 • 保守の主力メンバが若手世代に • フレームワークの情報が手にはいらない • ExportしたデータがImportできない • プログラミング言語のバージョンアップ • etc...etc... classmethod.jp 23
  24. 24. 外的要因による 「適応保守」 の方針は決めておこう classmethod.jp 24
  25. 25. まとめ classmethod.jp 25
  26. 26. 構築時から考えておこう • 保守計画・方針(バージョンアップ) • ドキュメントを残そう • Infrastructure as Code • 構成管理をしよう classmethod.jp 26
  27. 27. 体系的に学びたい人は ITIL v2 オススメ classmethod.jp 27
  28. 28. ご清聴ありがとうございました classmethod.jp 28

×