Upload
yoichiro-takehora
View
1.662
Download
0
Embed Size (px)
Citation preview
MTDDCMeetup TOHOKU2016
自治体Webサイトに求められるWebサイトパフォーマンスの要件
災害危機に対応できる表示速度と可用性
2016年6月25日竹洞陽一郎
自己紹介
� 株式会社Spelldata代表取締役社長� ACM(AssociationforComputingMachinery)会員� CMG(ComputerMeasurementGroup)会員� ISACA(InformationSystemsAuditandControlAssociation)会員� 日本統計学会賛助会員
� html5jパフォーマンス部部長� 統計学を基礎から学ぶ!中西塾主催
� Webサイトパフォーマンスに関係する仕事を始めて、もう13年目
� やってきた事� VMware…日本人初のVCPトレーナー� Akamai…プロフェッショナルサービス� VerizonBusiness…プリンシパルコンサルタント� KeynoteSystems…日本代表
今日、お話する内容
� 自治体サイトの重要性の変化
� 有事の際に繋がる自治体サイトにするために
� 計測データから見る緊急時の自治体サイトの理想
� 有事の際の自治体サイトの対策
� おまけ― 「データ」ではなくて、「情報」を配信する
従来の災害情報のチャネル
� 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%
従来のマスメディアの強みと弱み
� 出来るだけ多くの人々にとって、興味があるであろう、共通の情報を配信することが出来る点が強み。
� リアルタイムで変化する状況を配信するのは弱い。� 編集する必要性
� 興味を持つであろう人々や、情報の内容が多様化すると弱い。� 対象地域が色々と異なる
� 特定の地域の人々のみが対象� 短い期間だけの出来事
災害の局所化が進む中で、自治体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つのグループに分ける
制約の多いモバイルネットワーク
� 電波干渉という問題� ユーザがそこに多く居るからと言って、電波塔(基地局)は増やせない� 基地局を乱立するとどうなるか? – “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
災害発生地区
無事な地区
通信帯域を必要としているのは、どちらなのか?
非被災者は、災害情報を「消費」する
被災者は、災害情報を「生産」する
対策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㎝の高さの水が貯まる� まぁ、それくらいと思われてしまうかも…