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へのシステム移行と運用のポイント

111 views

Published on

2018/11/8 NHN テコラス株式会社

Published in: Business
  • Be the first to comment

  • Be the first to like this

初心者がおさえておきたいAWSへのシステム移行と運用のポイント

  1. 1. Copyright © NHN Techorus Corp. 初心者がおさえておきたい AWSへのシステム移行と運用のポイント NHN テコラス株式会社 2018/11/8
  2. 2. 今日お話すること システム移行と保守運用について • 移行する際のポイント • 保守運用(主に運用)についてのあれこれ 2
  3. 3. 運用の責任範囲 3 利用者の責任範囲 利用者側で可用性の確保が必要 データセンタ (ファシリティ・ネットワーク) OS ミドルウェア ハードウェア 仮想基盤 アプリケーション ユーザー AWS運用・移行支援サービス AWSの責任範囲 サービスで可用性を定義(SLA)
  4. 4. NHN テコラスの対応範囲 4 利用者の責任範囲 利用者側で可用性の確保が必要 データセンタ (ファシリティ・ネットワーク) OS ミドルウェア ハードウェア 仮想基盤 アプリケーション ユーザー AWS運用・移行支援サービス AWSの責任範囲 サービスで可用性を定義(SLA)
  5. 5. 移行する際のポイント 5
  6. 6. 移行時に気にしなければいけないことって何? 『何のために移行するのか?』 →様々な理由がある • システムを刷新したいから • オンプレミスのHW保守が切れるから(※) • 拠点の引っ越しや廃止があるから(※) • 上記(※)の様な事項の管理に気を病むことから開放されたいから 6
  7. 7. 移行時に気にしなければいけないことって何? 5W1Hで考えてみる 7
  8. 8. 移行時に気にしなければいけないことって何? 何時までに移行するのか?(When) • 期限(保守や契約)が切れるまでに • 可及的速やかに • とりあえずお試しで 8
  9. 9. 移行時に気にしなければいけないことって何? 何処へ移行するのか(Where) • パブリッククラウド • プライベートクラウド(基盤メンテナンスの束縛が…) • オンプレミス(また同じ…) 9
  10. 10. 誰が移行するのか?(Who) NHN テコラス (とお客様)が! 10 移行時に気にしなければいけないことって何?
  11. 11. 移行時に気にしなければいけないことって何? 何を移行するのか?(What) • 稼働しているシステムの全てを • システムの特定機能だけを ◦ストレージ ◦メール配信 ◦ドメイン管理 11
  12. 12. 移行時に気にしなければいけないことって何? 何故移行するのか?(Why) • 保守/保証ができなくなった基盤上で稼働させたくないから • ランニングコストを抑えたいから • その他、大人の事情で… 12
  13. 13. 移行時に気にしなければいけないことって何? どうやって移行するのか?(How) • システムをイメージ化して、クラウド上で再構築 • 必要なデータだけを取得して、新規構築 • 機器を準備して同期(rsync/replicate) 13
  14. 14. クラウドのメリット クラウドを使うメリットって? リソースの確保が比較的容易 サービス成長に伴う物理環境確保のために稟議 →各ディーラーに相見積もり→再稟議→etc,etc... その間に起こり得るサービススパイクや機器故障(連鎖しがち!) に怯える必要が無い 14
  15. 15. クラウドの選び方 クラウドの選択ってどうすれば? • それぞれのクラウドにもメリットがある • 使ってみたいって思うサービスがあるところが良い • その中でもAWSはかゆいところに手が届くものが多い • かつ工夫次第ですごく便利に使用できる 15
  16. 16. 保守運用(主に運用)についてのあれこれ 16
  17. 17. 運用ってなに? NHN テコラスの運用 お客様のサービスが継続的に運営できるように環境を監視して、 いち早く障害発生連絡と"お客様と共に"復旧対応を実施すること。 運用の定義 コンピュータシステム等のシステムが停止することなく、利用顧客に対してつつがな くサービスを提供できるよう当該環境を維持管理すること。 17 出典:https://ja.wikipedia.org/wiki/システム運用
  18. 18. 大前提 サービスって動いていて当たり前 18
  19. 19. 当たり前を実現するために サービスがどこで動いているのかは お客様からは見えない 19
  20. 20. 当たり前を実現するために サービスの正常稼働を継続するために • 見えない所(システム基盤)のケアに意外にリソースが取られる →サービスをより良くする為にエネルギーやリソースを費やしたい エネルギーやリソースを確保するために NHN テコラスが対応! • 保守運用や障害対応が注力するべき業務ではなくなる →「注力すべき本当の業務は?」と考えて実現することができる 20
  21. 21. そのために 餅は餅屋へ 21
  22. 22. 保守運用について AWSを利用する事で上記保守運用が軽減されるメリットが発生 保守運用の定義 保守運用ではサービスが提供不可となる事象を避けるためのリスク回避を前提として 業務がなされる。 例えばコンピュータに故障が発生していないか、不正使用された形跡がないか、障害 の兆候があらわれていないか、などといった事象を定期的に確認・監査する稼動評価、 メーカーが提供する障害対策パッチ情報などを確認してシステムへ適用する定例保守 作業、日々蓄積される業務データ等を有事の際に復旧させる事ができるようバック アップ取得や保管を行うバックアップ作業などが保守運用にあたる。 22 出典:https://ja.wikipedia.org/wiki/システム運用
  23. 23. AWSでインフラを運用するメリット 障害(予兆)検知に対する負荷軽減 今までよりも故障やその予兆を気にする必要がなくなる →しかしクラウドも(我々には)見えない機器で構成されている →サービスからの基盤障害通知には気をつけなければいけない 上記を解消する為に以下のような仕組みを準備する • CloudWatchのステータス変化に伴うアラームアクション • AWS CLIの定期実行によるステータスチェック →AWSが提供しているサービスやツールを利用することで 障害検知の確実性を高めていくことができる 23
  24. 24. AWSでインフラを運用するメリット 自動化で負荷を軽減(※) • セキュリティパッチ等に関しても情報収集が必須 →気が休まらない! • 自動化できる仕組み(AWS Systems Manager)導入で管理! (※)タイミングを調整したい場合は運用サービス側にお任せ • バックアップって定期的に取っておかないといけない… →当然スクリプトで自動化!も可能 • もちろんこちらの管理も運用サービス側にお任せ 24
  25. 25. AWSでインフラを運用するメリット 本来の業務に集中できるようになる! 25
  26. 26. 障害対応のポイント 障害対応 NHN テコラスの障害対応 • ベースはファーストエイド型 問題が発生しているという事実をいち早くお客様と共有しながら 復旧に向けて一次対応を進める • 定義したルールに則った迅速な対応 お客様が連絡を受けることのできないシチュエーションでも対応を進める 26 障害が発生した際にいち早くそれを検知する為の仕組みを組み込んで日々確認作業を 行う監視運用、障害箇所を調査・特定しサービス復旧に向け作業を行う障害対策など があたる。 出典:https://ja.wikipedia.org/wiki/システム運用
  27. 27. 障害対応のルール 対応ってどうやって考えればよいの? 考えるって言ったって雲をつかむような話だし.. →基本的なルールを考えることが大事 ルールの基準となる要素はお客様の希望がベースとなる ※全てを考えるのではなく運用側と一緒に考えることが必要かつ重要 27
  28. 28. 考えるポイント 判断基準の明確化 機械的にシステム状況を戻すだけならば全て自動化してしまうこと ができるが、どこかで必ず判断が必要になる • どこをロールバックさせたいのか/させたくないのか? • どのタイミングで戻すのか? お客様:業務的な見解から提案 NHN テコラス:蓄積されたノウハウと技術的見解にて提案 →お客さんと一緒に考えてNHN テコラスが実現/実施 28
  29. 29. 例:バックアップのポイント バックアップ業務、どの部分をどのように保管しておくか、 トラブルがあった場合にどのように戻すかをどう決めるか... • スクリプトで自動化! • 緊急時の手動での取得! • リストアタイミングはお客様の希望に合わせて自動/手動で • タスク管理は運用サービス側にお任せ 29
  30. 30. つまり… 障害が起きた時にどうしたいのか? が重要 30
  31. 31. では… 障害が起きたことを知るには? 31
  32. 32. 32 監視をするのです
  33. 33. 監視とは 障害が起きる予兆や起きた事象を検知する 監視って何をどんなふうにやってるの? • CloudWatchというAWS謹製のツールやオープンソースツールの ZabbixやIcingaなどのツールを使い、それぞれのアプリケーショ ンやサービスへ定期的なアクセスを実施する 例:特定のwebページにアクセスして、表示されているかどうか? 33
  34. 34. 障害対応とは 発生した障害を確認して正常な状態に戻す 障害対応って何をどんなふうにやってるの? • 監視ツールで監視していたアプリケーションやサービスから応答 がない場合や、通常の挙動と異なる事象や想定外の状態が発生し たら、メールなどのツールにて決められた連絡先に連絡を実施し て情報を共有したり、アプリケーションやサービスの再起動を 行ったりして、通常の状態に戻すための作業を実施する 34
  35. 35. 障害対応ってどんなことがあるの? 例: • バッチ処理のプロセスが落ちてしまった →とにかく連絡がほしい(1) • Webアプリが落ちてしまう →ECサイトで購入ができなくなるのは困るので戻してほしい(2) • アクセス過多でうまくサイトが表示されない →メンテナンスページへ誘導してほしい(3) 35
  36. 36. 障害対応の例 1.速報として何よりも先に電話連絡がほしい 何があってもとりあえずお客様側で把握しておきたいパターン 本ケースはお客様からの指示に従って対応を実施することが多い 36 メリット デメリット お客様側のサービス障害に対する初動が取りやすい 電話連絡にリソースが割かれてしまい、対応への 初動が少し遅れてしまう
  37. 37. 障害対応の例 2.復旧を最優先として対応を進めてほしい お客様への連絡・確認を減らすパターン 本ケースは予め手順やルールを定義しておいて対応を実施し、サー ビス復旧しない/できない場合のみ状況把握と対応をしたいという 要望の際に適応することが多い 37 メリット デメリット 定義された障害状況以外の連絡を受ける必要がない 復旧が難しいケースや想定外のケースが発生した際に お客様への連絡が遅くなってしまう
  38. 38. 障害対応の例 3.障害発生状況のみ連絡をくれれば良い サービスに多大に影響しない軽微な障害に適応するパターン 本ケースは根本的な改善対応は行うための情報として蓄積しておき たいという考え 38 メリット デメリット 即時対応の不要な障害連絡を受ける必要がない 重度の障害発生時でも認識が遅くなってしまう
  39. 39. 一般的な障害対応 通常は以下のような対応が一般的 • サービスに影響が出ている/出そうな障害 →電話連絡を行いながら障害対応を実施 • すぐにはサービスに影響しない障害(ディスク使用率等) →影響部の確認を実施してメールでの報告 39
  40. 40. 保守運用をアウトソースする場合のポイント 「ここだけはどうするか」ということを きちんとルール化することが必要 40
  41. 41. ルール決めのポイント 「ルールを決めると言われてもよくわからないし...」 → 「『Kiss』の法則」(※)にしたがってごくシンプルに考える ※ https://ja.wikipedia.org/wiki/KISSの原則 「Keep it simple, stupid.」/「Keep it short and simple.」 • 何が起きたら一番困るのかを定義する • その時にどんな対応をしなければいけないかを考える • その上でベーシックな方針や方向付けは運用側にお任せ 41
  42. 42. 運用をアウトソースするときに絶対にやってはいけないこと 『良い感じにやっておいて』 42
  43. 43. 運用をアウトソースするときに絶対にやってはいけないこと • 実は一番鬼門な依頼方法 • 感覚だけに頼った対応ほど危ういものはない • それぞれの「良い感じ」には相違がある 43
  44. 44. 運用アウトソースの失敗例 良い感じに対応しようとして 止めてはいけないプロセスを再起動 → セッション情報が全て消えて、サービスに多大な影響が発生 →「やってほしかったのはそれじゃなかった」という話になりがち 44
  45. 45. 運用アウトソースの失敗例 「専門スキルを持った人材が少なくMSP事業者に任せっきりに なっていたので、当社側ではAWSの構成、現状の設定や稼働 状況、どんな監視がされているかも全く把握できてない状況に 陥っていました。」 「プロジェクト管理ツールに過去の障害情報やMSP事業者の 対応履歴は残っているものの、まとまったドキュメントがなく、 現状を把握するためにはMSP事業者に逐一質問をするしかない 状態で障害発生のリスクを考えると運用に 不安を感じていました。」 ※参考 https://nhn-techorus.com/case/mizuno.html 45
  46. 46. • 基本的な対応ルール及び手順を策定 • 手順が存在する場合は手順を実施する • 存在しない場合はルールに即した対応を検討実施する • ただ対応を行う上でルールにも落とし込みきれない要素を感覚と して扱うことは必要 抑えておきたいポイント 46
  47. 47. 結論 保守運用に必要なことはオンプレミスも クラウドサービスでも変わらない 47
  48. 48. 目的を見失わないこと 以下が目的 • 予兆を検知していく →サービスが止まらないように • インシデントの原因となる問題(性能限界やボトルネック)を 見つけていく 上記を定常的に実施することで、 プロアクティブな対応、 より良いサービスを提供することができる (お客様&NHN テコラス) 48
  49. 49. NHN テコラスからの運用最適化のための提案 保守運用と障害対応から提案を導き出す 例:監視項目の変更や追加・削除 • 今までの監視項目では把握できない情報を取得して、システム状 況をよりわかりやすい形で把握する • ノイズとなっていた監視を削除することで、より的確な対応が実 施できる 49
  50. 50. NHN テコラスからの運用最適化のための提案 ナレッジに基づいた提案の実施 発生した障害の状況や履歴と弊社の蓄積してきた知見に基づいて、 スケールアップやスペックアップなどの提案を実施 • ディスク容量の増加 →ディスク増設やストレージへのデータエクスポート対応 • Webアクセス増に対応したい →AutoScalingを導入 • DBアクセス増に対応したい →リードレプリカの追加やAuroraへの移行 • cronでの処理が負荷の原因 →Lambdaへの移行 50
  51. 51. NHN テコラスからの運用最適化のための提案 ウェブサービスを運営しているが、現在よりも予算を抑えたい • リザーブドインスタンス適応(できるだけ現状の構成は崩さない) • スペックダウン+Auto Scaling(アクセス状況に応じた構成提案) ウェブサービスのアクセスをできるだけ負荷をかけずにさばきたい • 静的コンテンツの導入によるアクセス分散(簡易版) • CloudFront+S3の導入によるキャッシュアクセス有効化 障害耐性をより高めたい • LifeKeeperとDataKeeperを組み合わせたクラスタリング構成 • クロスリージョンフェイルオーバーによるDR対策 51
  52. 52. NHN テコラスからの運用最適化のための提案 保守運用に関する提案も実施 • 定常的な対応に関する確認ポイントの改善 • AWSで発行したワイルドカード証明書の導入 →無償で検証環境でもHTTPS通信の検証を実施可能 • 定期的なリソース状況の確認による適正サイズの提案 52
  53. 53. NHN テコラスからの運用最適化のための提案 お客様からの要望ももちろん取り入れる • ただ、依頼された内容を闇雲に受け入れるわけではない • 「本当に必要かどうか」を精査して「AではなくBなのでは?」 といった建設的な提示を行う 53
  54. 54. NHNテコラスが提供したいこと 皆さんが『やりたいこと』に 注力できるためのお手伝いをしたい 54
  55. 55. n h n - t e c h o r u s . c o m 55

×