matsuzawa-itの日記

人材派遣でIT系の仕事についている50目前のおじさんのブログです。仕事に追われ、趣味は釣りとロードバイクに乗ることと野菜を育てること。週1回の更新することを目標にボチボチがんばって生息しています。正社員という人並みの身分になれる日は来るのか( ´∀｀ )

AWS障害の振り返り記事から学ぶこと

ITコンサル IT

AWS障害があったと思いきや、楽天カードでログインできない・決済ができないなどのトラブルが発生したり（QTNetでの電源トラブルが発生原因）、日本電子計算のIaaS「Jip-Base」にシステム障害が発生して、東京都中野区など約50の自治体で、2019年12月5日も住民票の発行やホームページの閲覧などができない状態が続いていたり。。。

 

そんな中、下記記事が公開されています。

www.itmedia.co.jp

 

クラウドサービスでもデータが飛んだという事は聞いたことがあります。また訴訟にまで発展している例も下記のようにネットで紹介されています。

 

enterprisezine.jp

 

これら事例より、クラウドだから安心なんてことはないという事が証明されたと思います。データバックアップは常に考える、サービス継続を定義するのは重要です。

AWS振り返り記事でも

～～～～～～～～～～～～～～～

聞いていて感じたのは、エンジニアの人々は「落ちない設計」より「落ちにくい・落ちても迅速に復旧できる設計」を目指しているということだ。

～～～～～～～～～～～～～～～

と記述がある通り、自分も今の派遣先で設計するときには（実際設計検討をおこなっています）優先順位準備並べるてキーワードを書くと、キープシンプル、落ちても復旧しやすい、落ちにくい、という事を目指しています。

 

キープシンプル＝復旧しやすさというは両立できますが、落ちない設計はキープシンプルと両立しできない部分があります。特にクラスターソフトをインストールすると運用は大変です。

 

シンプルかつ復旧もしやすいですというキーワードより、コンテナー化を思い浮かべる人も多いかと思います。（職場ではコンテナー化・コンテナー化・コンテナー化とコンテナ化＝正義であると言い切る人もいますが・・・）ですが、コンテナ化を行うためには

  1. コンテナ化するアプリケーションを選定する
  2. コンテナでアプリケーションが動くようにする、適した設計にする
  3. Docker イメージをビルドする
  4. イメージレジストリに登録する

という手順を踏む必要があります。そしてコンテナ化に適した設計とは

The Twelve-factor App ( https://12factor.net/ja/ ) に代表される設計パターン
• 例：設定を環境変数に格納する
→ Systems Managerパラメータストア連携機能を利用し、よりセキュアに
• 例：コンテナ化するアプリはステートレスで動作するように
→ コンテナのメリットを最大限活かせる
• 例：永続化が必要なデータはコンテナ外に(バックエンドサービス)
→ RDBMSが必要…Amazon RDS、オブジェクトデータ保存…Amazon S3
• 例：ログをファイルで扱わずにストリームとして扱う
→ アプリケーションログはファイルでなく 標準出力/標準エラー出力 に
→ その上で awslogs ログドライバーを利用し、CloudWatch Logsへ転送

があります。

 

これだけで大変ですが、さらに逆にFargateはサーバなどの管理をAWS側に任せてコンテナを実行できる、いわゆる「サーバレス」のサービスを利用するとなると・・・

（詳しくは　スタートアップのためのコンテナ入門 – AWS Fargate 編 | AWS Startup ブログ　を参照）

 

 

と考えるとIaaSサービスは従来の手法が使えるから設計で悩むことは少ないですが、コンテナを考えると難しいものがありますね。ただし、サーバが壊れた場合の復旧に時間がかかるので思案しどころです。（コンテナ化＝サービスを落としやすく立ち上げやすい環境）

 

オンプレに戻るという事も検討する必要があります。

AWSのトラブルは5時間程度で大部分は復旧しました。データセンターの電源トラブルに起因するトラブル解消には、サーバ環境が壊れた場合の復旧時間は技術者の技術レベルおよびドキュメントがそろっているか？どこまでの障害をもともと想定していたのかなどの要因に左右されます。SaaSサービスを利用している場合はサービスが再開されるまでユーザに手出しできません。そして、どの方式であってもバックアップデータはユーザの自己責任です。

バックアップ手法によっては、マスターキーが鍵をなくした箱の中に入っておりカギを壊すしか中の書類（物）を取り出すことが出来ないという、あほな状態になることも考えられますから、ドキュメントを印刷して鍵のかかる書庫に保存する必要もあります。

 

このように多様化している技術を、どのように使うか、そもそもそのうえで構築するシステムはどの程度までサービス停止が許容できるのか？を考える必要があります。

 

ですので、自分ならば

・サービスの内容を考え、どこまでシステム停止ができるのかを定義する。

・最悪の事態が発生した場合、どこまでデータが残ればよいか（例えば1日前までなど）を定義する。

 ・システム停止の定義より、冗長化の範囲を定義する（運用コストも考慮する）

・サービス内容より、ミドルウェア（サーバ上で動作させるソフト）がコンテナ化できるかどうかを定義する

など、きちんと考えてドキュメントに落とし込んで定義を行い、「落ちにくい・落ちても迅速に復旧できる設計」を目指してシステム構築を行う必要があります。

システムを動作させるのも、「SaaS」「PaaS」「Iaas」「オンプレ（データセンターを含む）」と多様化しており、各技術を学び、メリットデメリットをしっかりと理解する必要があります。

 

勉強が大変ですが、面白い時代が到来していますね。

しっかり使い分け出来るように特徴を理解していく必要があります。