このページの本文へ

JAWS-UG近畿・中国レポート 第2回

バッドノウハウもしっかり学べるコミュニティならではの内容

そんな使い方あかん!やらかした事例満載のJAWS-UG大阪

2016年08月19日 07時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

ええバックアップってなにやねん(逢坂さん)

 続いて登壇したのは大阪の逢坂さんこと、NHNテコラス営業の逢坂文哉さん。「ええバックアップとあかんバックアップ」について語る。

FBのヅラ写真でおなじみ大阪の逢坂文哉さん、バックアップネタを披露

 自己紹介の後、逢坂さんは「みなさんEBS(Elastic Block Storage)のバックアップってどうしてます?」と聴衆に問いかける。逢坂さんはAWSに触れ始めた始めた頃、「EBSにはスナップショットがあるから大丈夫」だと思っていたが、すぐにスケジュール機能がないことに気がついたという。そこで、SEに「ええ感じのEBSバックアップするにはどないしたらいいんですか」と聞いたところ、「お客様の好み次第なんじゃないの?」という答えが返ってきたという。

 「好みってなんやねん」と考えた逢坂さんは、バックアップの定義に立ち返る。その結果として、「ええバックアップはとる目的が明確であること。その目的に対してコストが最適であること」という考えに至ったという。拠点障害、ハードウェア障害、OS・ソフトウェアのバグ、人為的なミスなどでデータが消失した際に、必要なデータが戻せるというのが重要なわけだ。

 翻ってAWSのデータ保存場所になることの多いEBSを見ると、そもそも可用性や耐久性がかなり高いという点が浮き彫りになる。AZ内の複数のサーバーにデータがレプリケートされているし、可用性も99.999%。年間の故障率が0.1~0.2%で設計されているので、1000ボリュームで1つか、2つ壊れるくらいで済む。「じゃあ、EBS信じれば、バックアップとらなければいいんじゃない」という気持ちもわき上がるが、実際、拠点障害やハードウェア障害には対応できるが、OSやミドルウェア障害、バグによるデータ消失、攻撃によるデータ改ざん、人為的なミスによるデータ消失には対応できないのも事実。やはりバックアップは必要という結論に至る。

可用性も高いEBSだけど、やっぱりバックアップは必要です

 ではどんなバックアップがよいか? まずバックアップ先としては、イレブンナインの可用性を持つAmazon S3、S3のスナップショット、3つ目は最近出たAmazon EFSなどが挙げられる。営業が気になる値段を調べてみると、S3が0.033ドル/1GB(東京)なのに対し、S3のスナップショットは約3倍の0.095ドル/1GB(東京)、EFSは約10倍の0.33ドル/1GB(アイルランド)になる。おのずとEFSは候補から除外され、S3とS3スナップショットでのバックアップに絞られる。

S3、S3スナップショット、EFSでのコスト比較。営業としてはやはりコストが気になります

 手段としては当然手動があるが、さすがに面倒。そのため、Goで書かれたgoofysでS3をマウントし、cronでrsyncを用いたり、同じくcronで“aws s3 sync”コマンドを叩く。あるいはスナップショットの場合も、cronでコマンドを叩くか、Lambdaのファンクションでスナップショットを定期的に取得するのがよいという。

 ここで前述した目的に照らすと、万が一消してしまった場合に、1世代前のバックアップを取得する場合はcronで“aws s3 sync”コマンドを叩く。OSやミドルウェアの論理障害でバックアップを戻す場合は、Lambdaファンクションでスナップショットをとるのがお勧めだという。逢坂さんは、「これがSEが言ってた、お客さんの好みってことなのかなと、長い試行錯誤の後に気づいたことです」とまとめた。

サービス止まってもどうにもなる使い方を考えよう(山下さん)

 続いての登壇は中央電力情シスの山下光洋さん。「AWS自体は使って1年くらい。この1年くらいで失敗してきたことを話していこうと思います」と挨拶した山下さんは、AWSで困った経験談を語った。

中央電力の情シスでAWSを使う山下光洋さん。セミナー修了後、一等地からの夜景をおがませてくれた

 山下さんの失敗談の多くは、設定ミスや時間がかかったといった例。たとえば、「EC2が空っぽになっていたら、リージョンが違っていた」「LambdaのデバッグがCloudWatchに反映されるのに時間がかかる」「保存ボタンを押しても、デプロイをしないとAPI Gatewayの設定が反映されない」「CloudFrontでS3にリダイレクトができなかった」など。

 また、Multi-AZだから大丈夫だと思い、稼働時間にインスタンスクラスを変更する、あるいはCloudFrontでACM(Amazon Certificate Manager)が選択できないといったトラブルは時間が解消してくれたトラブル。さらに、Route53でドメインを購入したら別のところから請求が来て、経理から怒られたという例もあったという。

別請求でRoute53のドメインを購入して、経理から怒られる

 山下さんは、「クラウドサービスの場合、自分の手の届かないことで、どうしようもなくなることもある。なので、1つか2つ止まったところで、どうにでもなるような使い方を考えるべきではないか」とまとめる。これを実現するため、AWSの冗長化や自動復旧などの手段を積極的に活用していくべきとアピールした。1年前までオンプレ中心だった情シスの山下さんからすると、自分の手の届かないクラウドにはいろいろ驚きも多かったようだ。

カテゴリートップへ

この連載の記事