オルタナティブ・ブログ > Mostly Harmless >

IT技術についてのトレンドや、ベンダーの戦略についての考察などを書いていきます。

「アクセス集中によるシステムダウン」が無くならないのは何故なのか?

»

先週、ヤマト運輸でシステム障害が発生し、クラウドサービスが利用できなくなったというニュースがありました。

ヤマト運輸の送り状発行システム「B2クラウド」が復旧 原因は「アクセス集中など」

原因は、タイトルにもあるように「アクセス集中など」ということですが、何故アクセスが集中したのかなどはわかっていないようです。

しかし、この種のニュースを見る度に思うのが、

オートスケールになっていなかったのか?

ということです。

オンプレミスに対するクラウドのメリットとして、かなりわかりやすいものの一つだと思うのですが。今回の記事にはまだわからない部分が多くて、オートスケールについても書いていないのですが、実際にはどうだったのでしょうか?

TOKYO2020のチケット予約の時にもアクセス集中のニュースがあって、「事前にわかりきってるんだから、用意しておけば良いのに。」と思ったのですが、これもオートスケールについて

  1. 採用していたのにうまく機能しなかった
  2. 検討したけれども採用しなかった
  3. 存在を知らなかった

のどれだったのか、書いている記事は見当たりません。こちらの方がオートスケールに言及していますが、他には引っかかってきませんね。

tsumitate_woman.pngオートスケールはクラウドの強み

オートスケールというのはその名のとおり、負荷の状況に応じて仮想マシンの台数を自動的に増減する機能です。高負荷時には仮想マシンを増やして、アクセスしにくくなったりシステムがダウンするのを回避し、軽負荷時には台数を減らしてコストを抑えることができます。

クラウドが始まった頃、そのメリットとして、ハードウェアなどの資産を持たなくて済むことがあげられました。持たなくて済むことで、必要なときに必要な台数だけ利用することができるということです。負荷が高まった時にサーバーの台数を増やすのはオンプレミスでもできますが、一度購入してしまうと、減らすというのは用意ではありません。クラウドはそれが簡単にできるため、大きなメリットと考えられたのです。AWSのEC2は「Amazon Elastic Compute Cloud」の略ですが、Elasticには「弾力性」「伸縮自在」という意味があります。

最初の頃はユーザー側でシステムの負荷を監視しながら仮想マシンの台数を増減させなければならないという、かなりハードルの高いものでしたが、当然その後自動化されました。オートスケールがいつ頃から始まったのか、調べたのですがよくわからないのですが、以下の記事中に「Amazon Auto Scaling」の記述がありますので、2009年には既にサービスとしては存在していたと思われます。

第3回 クラウド上でスケールアウトするシステムの作り方と実例

もう10年以上の歴史があるわけですから、もっとオートスケールを利用して、アクセスの集中に強いシステムが増えても良さそうなものですが、実際にはアクセス集中によるシステムダウンのニュースは減ったように思えません。

「オートスケール」って、使われてるの?

ITmediaには、「アクセス集中」関連のニュースを集めたページまであります。

「アクセス集中」関連の最新 ニュース・レビュー・解説 記事 まとめ

この中の記事をいくつか読んでみたのですが、オートスケールについて触れている記事は無いようですね。あまりにあたりまえなので書かないのか、それとも誰も使っていないのか?

検索するとオートスケールの導入事例は沢山出てくるので、

オートスケール基盤とAWS運用監視(マネージド)のアウトソーシング

少なくとも、使われていないということは無さそうです。何らかの理由でオートスケーリングを導入していないサイトが障害を起こし、それが報道され、印象として減っていないように見えるということなのでしょうか。

コストや自社以外のシステムが問題となる場合も

しかし、さらに調べてみると、オートスケールと言っても良いことばかりでは無いようです。

オートスケール機能のついたクラウド型サーバーを解約した2つの理由

このケースでは、コストが問題になっています。いくらサービスが落ちなくても、コストが数倍かかることを許容できるかどうかということは、良く考える必要があるでしょう。上限などいろいろ設定はあるのでしょうが、それを使いこなすためにもいろいろなスキルが必要そうです。

また、その他の課題として、外部システムとの連携があります。

PayPay"100億円祭"の裏側で何があったのか システム障害と苦闘したエンジニア (1/2)

この記事では、オートスケールになっていたかどうかについては言及がありませんが、AWSベースでマイクロサービスアーキテクチャを採用とありますから、かなり先進的なシステムと言えます。その中に、

システム障害の原因の1つに、外部決済システム(ヤフー)と連携するサービスのリソースが不十分だった

という話が出てきます。外部の決済システムに履歴を問い合わせるクエリは負荷が高く、それが高頻度で発生したためにそこが「詰まって」しまったということです。現代のシステムは様々な外部システムと連携しており、そこの負荷想定が十分でなかったということでしょう。自社システムだけで完結できない場合、こういったリスクもあるということですね。特に決済系ではこういったことが起こりがちなのかも知れません。

また、こんな記事がありました。

「費用度外視でサーバ増やせ」→「無駄なサーバ減らせ」に方針転換 スマホゲーム「シノアリス」運営の裏話

失敗した話も多く、なかなか臨場感があって面白かったのですが、この記事にもオートスケールの話は出てきません。

「パフォーマンスを低下させず、費用を大幅に削るのは並大抵のことではなかった」というように、ゲームというある意味究極のコストパフォーマンスを追求する世界では、まだまだ「お任せでなんとか」みたいなお気楽な話では無いのかも知れませんね。

実際には、オートスケールに対応したシステムは増えているのではないかと思います。問題を起こさなければ報道されませんから、増加が見えないだけなのではないでしょうか。しかし一方で、クラウドサービス利用の裾野が広がるにつれ、オートスケールを(何らかの理由で)採用していなかったり、オートスケールに向かないサービスも一定の割合で増えてきて、そういったシステムの障害が報道されることで実際には減っていないように見えるのかも知れません。

クラウドには多くの可能性がありますが、まだまだ「お任せ」できない部分も多いということなのでしょう。それを適切に使いこなすためには、ユーザー側にも不断の努力と勉強が求められます。

 

「?」をそのままにしておかないために

figure_question.png時代の変化は速く、特にITの分野での技術革新、環境変化は激しく、時代のトレンドに取り残されることは企業にとって大きなリスクとなります。しかし、一歩引いて様々な技術革新を見ていくと、「まったく未知の技術」など、そうそうありません。ほとんどの技術は過去の技術の延長線上にあり、異分野の技術と組み合わせることで新しい技術となっていることが多いのです。

アプライド・マーケティングでは、ITの技術トレンドを技術間の関係性と歴史の視点から俯瞰し、技術の本質を理解し、これからのトレンドを予測するためのセミナーや勉強会を開催しています。是非、お気軽にお問い合わせ下さい。

Comment(0)

コメント

コメントを投稿する