MTDDCMeetup TOHOKU2016

自治体Webサイトに求められるWebサイトパフォーマンスの要件

災害危機に対応できる表示速度と可用性

2016年6月25日竹洞陽一郎

yoichiro.takehora@spelldata.co.jp

自己紹介

� 株式会社Spelldata代表取締役社長� ACM(AssociationforComputingMachinery)会員� CMG(ComputerMeasurementGroup)会員� ISACA(InformationSystemsAuditandControlAssociation)会員� 日本統計学会賛助会員

� html5jパフォーマンス部部長� 統計学を基礎から学ぶ!中西塾主催

� Webサイトパフォーマンスに関係する仕事を始めて、もう13年目

� やってきた事� VMware…日本人初のVCPトレーナー� Akamai…プロフェッショナルサービス� VerizonBusiness…プリンシパルコンサルタント� KeynoteSystems…日本代表

株式会社Spelldata

Webサイトパフォーマンス品質評価証明書

Webサイトパフォーマンスについて

Webサイトパフォーマンス管理の基本

統計学を基礎から学ぶ!中西塾第一期2014～2015

統計学を基礎から学ぶ!中西塾第二期2016/4～

「第7章コンテンツの解析」配信品質と情報品質

ProjectICHIGANのネットワーク設計を担当

今日、お話する内容

� 自治体サイトの重要性の変化

� 有事の際に繋がる自治体サイトにするために

� 計測データから見る緊急時の自治体サイトの理想

� 有事の際の自治体サイトの対策

� おまけ― 「データ」ではなくて、「情報」を配信する

自治体サイトの重要性の変化無事よりも有事に注目される、その存在意義

2014年10月31日横浜市総務局危機管理室

2015年9月10日仙台市

2016年4月14日熊本県

変わりゆく自治体Webサイトの役目

従来の災害情報のチャネル

� TV� ラジオ

� 広報車

� 防災無線スピーカー

� 町内会

昨今の災害情報のチャネル

� Webサイト� Twitter� 災害速報メール

� TV� ラジオ

災害情報伝達のチャネルの変化

単純にインターネットが普及しただけではなく、従来のメディアでは、「災害の局所化」＝「対象情報の複雑化・断片化」に対応できないという背景がある

災害の局所化

� 都市圏への人口集中が激しくなっている� 都市基盤の整備では、経済的側面から、全てを強化することはできない� 地下街の開発→地下への浸水の問題� 超高層建築物→想定していない新しい側面が生み出す、新しい災害

� 人口の現象と高齢化社会に伴う限界集落の問題� 集落の「集団」の力で対応できなくなって、災害化してしまう

� 森林の持つ多面的機能の持続性維持が損なわれつつある� 森林の荒廃に伴う、保安林としての機能不全

� 社会インフラの老朽化

� 地球温暖化の影響の加速

社会インフラの老朽化

建設後50年を経過する社会資本の割合

2013年3月 2023年3月 2033年3月

道路橋（橋長2m以上の橋70万の内の40万橋。残り30万橋は、建築年度不明）

約18% 約43% 約67%

トンネル（約1万本。建築年度不明の約250本を除く）

約20% 約34% 約50%

河川管理施設（水門等）（約1万施設）

約25% 約43% 約64%

下水道管渠（総延長約45万Km）

約2% 約9% 約24%

港湾岸壁（約5千施設、水深-4.5m以深）

約8% 約32% 約58%

日本列島を襲う「水道管破裂」老朽化の波が押し寄せる年間2万5000件の事故

http://news.yahoo.co.jp/feature/167

地球温暖化

http://www.climate-lab-book.ac.uk/files/2016/05/spiral_optimized.gif

ゲリラ豪雨（局地豪雨）―渋谷の例

竜巻発生の増大化

従来のメディアによる災害情報1対1の関係

現在のメディアによる災害情報Webへの誘導

「詳細は、各自治体のWebサイトで確認してください。」

従来のマスメディアの強みと弱み

� 出来るだけ多くの人々にとって、興味があるであろう、共通の情報を配信することが出来る点が強み。

� リアルタイムで変化する状況を配信するのは弱い。� 編集する必要性

� 興味を持つであろう人々や、情報の内容が多様化すると弱い。� 対象地域が色々と異なる

� 特定の地域の人々のみが対象� 短い期間だけの出来事

TVで、どこまで細かい情報を伝えられるか?

災害の局所化が進む中で、自治体Webサイトが果たすべき役割は大きい

� きめ細やかな情報の提供

� 迅速な情報の提供

� 信用できる情報の提供

� 災害対応に強い自治体は、自治体そのもののブランディング化に繋がる� 子育て支援自治体

� リモートワーク支援自治体� スタートアップ支援自治体� 「災害対応に強い自治体」

� ハードウェア面（モノ）ではなく、ソフトウェア面(ヒト)を見て考える� ハードウェア（箱モノ）に依存する不動産価値ではなく、ソフトウェア（共同体、体制、文化）に基づく不動産価値が、自治体の価値を高める

有事の際に繋がる自治体サイトにするためにネットワークの出口を考えておく

BSC BaseStationControllerBTS BaseTransceiverStationCDR CallDetailRecordCIMD ComputerInterfacetoMessageDistributionGGSN Gateway GPRSSupportNodeGMSC Gateway MSCGPRS GeneralPackedRadioService(2.5G)GSM GlobalSystemforMobileCommunication(2G)HLR HomeLocationRecordIP InternetProtocolISDN IntegratedServiceDigitalNetworkISUP ISDNUserPartLTE LongTermEvolution(4G)MGW MediaGatewayMMSC MMSCentreMSC MobileSwitchingCentrePBX PrivateBranchExchangePSTN PublicSwitchedTelephoneNetworkRNC RadioNetworkControlSGSN ServingGPRSNodeSITE SIGOSIntegratedTestEnvironmentSMPP ShortMessagePeertoPeerSMSC ShortMessageServiceCentreUCP UniversalComputerProtocolUMTS UniversalMobileTelecommunications

System(3G)UTRAN UMTSTerrestrial AccessNetworkVLR VisitorLocationRegister

携帯網のネットワークトポロジー

インターネットから携帯ネットワークを経由してスマートフォンへ

電波は有限資源

� NTTドコモの800MHz帯の例� 総務省から15MHzの幅をもらっている� それを12.5KHz幅で区切る� 15MHz/12.5KHz=1200チャネル

� 7つのグルーピングを作るとすると、各基地局は1200/7≒170チャネルとなる。� 四色定理から、4つのグループをつくれば十分だが、それでは、基地局設計がギチギチになってしまうので、ゆとりを持つために7つのグループに分ける

電波の「傘」（周波数）をぶつからないように置いて、雨に濡れない（電波が途切れない）ようにして歩く

四色問題→四色定理

� 隣接する領域が異なる色になるように塗り分けるには、何色あれば良いのか?

� 1976年に、ケネス・アッペルとヴォルフガング・ハーケンが四色定理をコンピュータを使って証明

郊外の基地局配置1つの円で20～30Kmをカバー。その分、電波が強い。

色の違い＝チャネルのグループの違い。

郊外の携帯網の基地局設計

都市部の基地局配置1つの円で200～300mをカバー。その分、電波が弱い。

都市部の携帯網の基地局設計

ソフトバンクの「マイクロセル化」

制約の多いモバイルネットワーク

� 電波干渉という問題� ユーザがそこに多く居るからと言って、電波塔（基地局）は増やせない� 基地局を乱立するとどうなるか? – “Dirty WiFi”と同じ状況に� 電波の「谷間」～基地局と基地局の中間点

� 「繋がる」事と「通信できる」事は、違う� アンテナの表示が5本中5本立った! →電波強度が十分というだけ� 携帯基地局は、混雑するとネットワークを守るためにパケットを意図的にドロップする

� レイテンシの問題� モバイルネットワークのレイテンシは3Gで100～200ms、4Gで40〜60ms

2016年6月25日 39 ©2012Keynote Systems,Inc..

携帯網のパケットドロップ率の影響

�無線基地局のパケットドロップ率が20%、1パケット1KB（計算用の仮定）

1.全部で100KBのデータを送信する場合� 失敗回数の期待値＝{100×(1-0.8)}÷0.8=25� 失敗回数の分散={100×(1-0.8)}÷0.8^2 =31.25� 失敗回数の標準偏差は、31.25の平方根、約6となります。� 2σの考え方だと、下値＝失敗回数の期待値－2×失敗回数の分散の平方根上値＝失敗回数の期待値＋2×失敗回数の分散の平方根

� 2σ（シグマ）の範囲を計算すると、(25－2×6, 25+2×6)=(13, 37)95%の確率で13～37回の失敗（パケットドロップ）が発生します。

2.全部で1,000KBのデータを送信する場合� 失敗回数の期待値＝{1,000×(1-0.8)}÷0.8=250� 失敗回数の分散={1,000×(1-0.8)}÷0.8^2 =312.5� 失敗回数の標準偏差は、312.5の平方根、約18となります。� 2σ（シグマ）の範囲を計算すると、(250－2×18, 250+2×18)=(214, 286)95%の確率で214～286回の失敗（パケットドロップ）が発生します。

ありがちな勘違い

� サーバが高速化されれば良い� 出口の混雑の問題は解決しない

� CDNを入れれば良い� 出口の混雑の問題は解決しない

� 軽量化すれば良い� 皆さんが想像している以上の軽量化が必要

� キャッシュを効かせればよい� ブラウザキャッシュ？

� サーバサイドキャッシュ？� 状況の変化が見通せるならどうぞ。普通は怖くてできない。

入口も出口も、双方、考える

ここも大事

こっちはもっと大事

災害が発生している地区と無事な地区が同じ基地局内に存在する場合

半径2Km

災害発生地区

無事な地区

通信帯域を必要としているのは、どちらなのか?

熊本の震災でのLINE通話10分無料の問題

災害時、通信帯域は貴重。人命をも左右する。

社会心理学者レヴィンの概念式

B = F(P・E)B=行動、P=人の状態、E=環境

人の行動は、その人の状態と環境によって決まる

被災者と非被災者の「災害」状態の違いが引き起こす行動の違い

半径2Km

災害発生地区

無事な地区

通信帯域を必要としているのは、どちらなのか?

非被災者は、災害情報を「消費」する

被災者は、災害情報を「生産」する

計測データから見る緊急時の自治体サイトの理想計測データが、理想の容量を教えてくれる

仙台市のサイトの場合

散布図ダウンロード完了時間―デスクトップwww.city.sendai.jp

読み込みの遅延

配信が止まる

ヒストグラムダウンロード完了時間 ―デスクトップ

ヒストグラム表示開始時間―デスクトップ

ヒストグラム表示完了時間－デスクトップ

散布図ダウンロード完了時間―スマートフォンwww.city.sendai.jp

ヒストグラムダウンロード完了時間 ―スマートフォン

ヒストグラム表示開始時間―スマートフォン

ヒストグラム表示完了時間－スマートフォン

散布図ダウンロード完了時間―デスクトップwww.city.sendai.jp/bousai/index.html

画像が足を引っ張っている

青色は、読込時間を指す。つまり、全般的に、ディスクアクセスの遅延が目立つ

画像配信の遅延～待機時間

橙色は、待機時間を指す。つまり、全般的に、CPUやメモリの不足が目立つ

ヒストグラムダウンロード完了時間 ―デスクトップ

ヒストグラム表示開始時間―デスクトップ

ヒストグラム表示完了時間―デスクトップ

散布図ダウンロード完了時間―スマートフォンwww.city.sendai.jp/bousai/index.html

GoogleアナリティクスのSSL接続が足を引っ張る

オレンジ色の箇所はSSL。Googleアナリティクスは、いつも遅延要因。

ヒストグラムダウンロード完了時間 ―スマートフォン

ヒストグラム表示開始時間―スマートフォン

ヒストグラム表示完了時間―スマートフォン

熊本市のサイトの場合

散布図ダウンロード完了時間 ―スマートフォン

速さの秘密

ウォーターフォール図―スマートフォン

ヒストグラムダウンロード完了時間 ―スマートフォン

ヒストグラム表示開始時間―スマートフォン

ヒストグラム表示完了時間―スマートフォン

Yahoo! Japanの場合

散布図ダウンロード完了時間 ―スマートフォン

400KBを超えたら、もうダメ…エラーもある…

接続エラー

接続エラーが発生すると、足を引っ張る

ヒストグラムダウンロード完了時間 ―スマートフォン

ヒストグラム表示開始時間―スマートフォン

ヒストグラム表示完了時間―スマートフォン

Spelldataの場合

300KBでこの秒数

ウォーターフォール図

ヒストグラムダウンロード完了時間 ―スマートフォン

ヒストグラム表示開始時間―スマートフォン

ヒストグラム表示完了時間―スマートフォン

有事の際の自治体サイトの対策具体的処方箋

対策1： 有事の際には、有事用サイトに切り替える

� HTML+CSSを基本にする� 動的ページを止めて、静的ページへ移行する

� どうしても必要な場合のみ、画像を入れる

� 1ページの容量を100KB以下にする� 状況に応じて、50KBまで減らす

� アクセス解析など、一切のサードパーティーコンテンツを外す

� SNSのボタンは遅延要因なので外す� どうしてもボタンを付けたい場合は、自作にしておく

携帯網の可用性やパフォーマンスでは、上り路線だけではなく、下り路線を考えないといけない

対策2:サーバの負荷をどこかに受けてもらう

� AWS S3のようなオンラインストレージ� 10TBの転送量があったとしても、月3万円強で済む� 初の1GB転送量で、0.033ドル（3.3円）� 使えば使うほど安くなる

� CDNの活用� Fastlyお勧め� ディベロッパーアカウントは月5000円から使える� チャージしておいて、緊急時にだけ使うという使用方法もあり

対策3:情報伝達経路のマルチチャネル化

� 全ての情報伝達経路をインターネットにしない� 身の安全を確保した市民は、できるだけ、携帯網を使わないようにしてもらう

� 避難勧告や救助情報、支援情報など、今、目の前の危機に対処する人のために、携帯網の回線を開けてあげる、という事を市民に協力依頼する重要性

� インターネットでも、携帯網よりは、有線回線網を勧める

� TV、ラジオなどのマスメディアを通じた協力依頼� 連絡網の全てをインターネットに依存しない仕組みづくり

� 主要な連絡係には、携帯網を使った通信で、連絡係から避難所の人々には口頭で伝える、伝言板で伝える、館内放送で伝えるなど

� 既存の仕組みを上手く活用する� 電話会社や携帯会社、GoogleやFacebookなど、各社が提供している災害時の情報伝達網を活用する

市民のITリテラシーを上げる重要性

� 今後、災害が増えることはあっても、減ることは無い� 各種の状況がそれを示唆している

� 市民ひとり一人のITリテラシーを上げる事は、災害から身を守ることに直結する

「一見どうみえようとも、それはつねに人の問題である。」―G・M・ワインバーグ� 問題を、広義の意味でのハードウェアのせいにして、ハードウェアで解決しようとしてはいけない。

� 問題は、広義の意味でのソフトウェア、人に依存する問題である。

� 人にフォーカスしましょう。我々、人間は、学ぶことができるのです。

おまけ

「データ」ではなくて、「情報」を配信する高速に「データ」を送れば、それで良いわけではない。高速に「情報」を送る。

価値ある情報＝理解できる情報を高速に配信する

� 1時間に100ミリの雨量� 分からない

� 1時間で6畳（約10㎡）の部屋に1トンの水が貯まるぐらいの量� 凄さが分かる

� 1時間で6畳の部屋に、牛乳パック1000本分の水が貯まる� 逆に軽くみられるかも…

� 1時間で6畳の部屋に、10㎝の高さの水が貯まる� まぁ、それくらいと思われてしまうかも…

Q&A