自治体サイトに求められるWebサイトパフォーマンスの要件
•
7 recomendaciones•3,512 vistas
自治体のWebサイトは平時よりも緊急時の方が表示速度や可用性が高度に求められ、特に、災害時の自治体のWebサイトの情報発信は、時に人の命に関わる事もあります。 昨今の地球温暖化の影響と社会インフラの老朽化に伴い、今後ますます住民や、他の公共組織や民間組織などの関係各組織に滞りなく情報発信できるかどうかが大きな鍵を握ります。 では、どのように緊急時のWebサイトの表示速度や可用性を担保すれば良いかについては、実際のところ、殆どノウハウが公開されていません。 このセッションでは、緊急時に起こりうる突発的なアクセスの急増に耐えつつ、かつ高速に重要な情報を配信するための、表示速度と可用性の設計や運用について概要を解説します。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (14)
Destacado
Destacado (15)
Similar a 自治体サイトに求められるWebサイトパフォーマンスの要件
Similar a 自治体サイトに求められるWebサイトパフォーマンスの要件 (20)
Más de Yoichiro Takehora
Más de Yoichiro Takehora (11)
自治体サイトに求められるWebサイトパフォーマンスの要件
- 1. MTDDC Meetup TOHOKU 2016 自治体Webサイトに求められる Webサイトパフォーマンスの要件 災害危機に対応できる表示速度と可用性 2016年6月25日 竹洞 陽一郎 yoichiro.takehora@spelldata.co.jp
- 2. 自己紹介 – 株式会社Spelldata 代表取締役社長 – ACM(Association for Computing Machinery)会員 – CMG(Computer Measurement Group)会員 – ISACA(Information Systems Audit and Control Association)会員 – 日本統計学会賛助会員 – html5j パフォーマンス部部長 – 統計学を基礎から学ぶ! 中西塾主催 – Webサイトパフォーマンスに関係する仕事を始めて、もう13年目 – やってきた事 – VMware … 日本人初のVCPトレーナー – Akamai … プロフェッショナルサービス – Verizon Business … プリンシパルコンサルタント – Keynote Systems … 日本代表
- 11. 今日、お話する内容 – 自治体サイトの重要性の変化 – 有事の際に繋がる自治体サイトにするために – 計測データから見る緊急時の自治体サイトの理想 – 有事の際の自治体サイトの対策 – おまけ ― 「データ」ではなくて、「情報」を配信する
- 14. 2015年9月10日 仙台市
- 15. 2016年4月14日 熊本県
- 17. 従来の災害情報のチャネル – TV – ラジオ – 広報車 – 防災無線スピーカー – 町内会 昨今の災害情報のチャネル – Webサイト – Twitter – 災害速報メール – TV – ラジオ 災害情報伝達のチャネルの変化 単純にインターネットが普及しただけではなく、従来のメディアでは、 「災害の局所化」＝「対象情報の複雑化・断片化」に対応できないと いう背景がある
- 18. 災害の局所化 – 都市圏への人口集中が激しくなっている – 都市基盤の整備では、経済的側面から、全てを強化することはできない – 地下街の開発→地下への浸水の問題 – 超高層建築物→想定していない新しい側面が生み出す、新しい災害 – 人口の現象と高齢化社会に伴う限界集落の問題 – 集落の「集団」の力で対応できなくなって、災害化してしまう – 森林の持つ多面的機能の持続性維持が損なわれつつある – 森林の荒廃に伴う、保安林としての機能不全 – 社会インフラの老朽化 – 地球温暖化の影響の加速
- 19. 社会インフラの老朽化
- 20. 建設後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%
- 23. ゲリラ豪雨（局地豪雨）―渋谷の例
- 24. 竜巻発生の増大化
- 27. 従来のマスメディアの強みと弱み – 出来るだけ多くの人々にとって、興味があるであろう、共通の情報を 配信することが出来る点が強み。 – リアルタイムで変化する状況を配信するのは弱い。 – 編集する必要性 – 興味を持つであろう人々や、情報の内容が多様化すると弱い。 – 対象地域が色々と異なる – 特定の地域の人々のみが対象 – 短い期間だけの出来事
- 29. 災害の局所化が進む中で、 自治体Webサイトが果たすべき役割は大きい – きめ細やかな情報の提供 – 迅速な情報の提供 – 信用できる情報の提供 – 災害対応に強い自治体は、自治体そのもののブランディング化に繋 がる – 子育て支援自治体 – リモートワーク支援自治体 – スタートアップ支援自治体 – 「災害対応に強い自治体」 – ハードウェア面（モノ）ではなく、ソフトウェア面(ヒト)を見て考える – ハードウェア（箱モノ）に依存する不動産価値ではなく、ソフトウェア（共同体、体制、文 化）に基づく不動産価値が、自治体の価値を高める
- 31. BSC Base Station Controller BTS Base Transceiver Station CDR Call Detail Record CIMD Computer Interface to Message Distribution GGSN Gateway GPRS Support Node GMSC Gateway MSC GPRS General Packed Radio Service (2.5G) GSM Global System for Mobile Communication (2G) HLR Home Location Record IP Internet Protocol ISDN Integrated Service Digital Network ISUP ISDN User Part LTE Long Term Evolution (4G) MGW Media Gateway MMSC MMS Centre MSC Mobile Switching Centre PBX Private Branch Exchange PSTN Public Switched Telephone Network RNC Radio Network Control SGSN Serving GPRS Node SITE SIGOS Integrated Test Environment SMPP Short Message Peer to Peer SMSC Short Message Service Centre UCP Universal Computer Protocol UMTS Universal Mobile Telecommunications System (3G) UTRAN UMTS Terrestrial Access Network VLR Visitor Location Register 携帯網のネットワークトポロジー
- 33. 電波は有限資源 – NTTドコモの800MHz帯の例 – 総務省から15MHzの幅をもらっている – それを12.5KHz幅で区切る – 15MHz/12.5KHz = 1200チャネル – 7つのグルーピングを作るとすると、各基地局は 1200/7≒170チャネルとなる。 – 四色定理から、4つのグループをつくれば十分だが、それでは、 基地局設計がギチギチになってしまうので、ゆとりを持つために7 つのグループに分ける
- 38. ソフトバンクの「マイクロセル化」
- 39. 制約の多いモバイルネットワーク – 電波干渉という問題 – ユーザがそこに多く居るからと言って、電波塔（基地局）は増やせない – 基地局を乱立するとどうなるか? – “Dirty WiFi”と同じ状況に – 電波の「谷間」～基地局と基地局の中間点 – 「繋がる」事と「通信できる」事は、違う – アンテナの表示が5本中5本立った! → 電波強度が十分というだけ – 携帯基地局は、混雑するとネットワークを守るためにパケットを意図的にド ロップする – レイテンシの問題 – モバイルネットワークのレイテンシは3Gで100～200ms、4Gで40〜60ms 2016年6月25日 39 ©2012 Keynote Systems, Inc..
- 40. 携帯網のパケットドロップ率の影響 – 無線基地局のパケットドロップ率が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回の失敗（パケットドロップ）が発生します。
- 41. ありがちな勘違い – サーバが高速化されれば良い – 出口の混雑の問題は解決しない – CDNを入れれば良い – 出口の混雑の問題は解決しない – 軽量化すれば良い – 皆さんが想像している以上の軽量化が必要 – キャッシュを効かせればよい – ブラウザキャッシュ？ – サーバサイドキャッシュ？ – 状況の変化が見通せるならどうぞ。普通は怖くてできない。
- 48. 仙台市のサイトの場合
- 50. 読み込みの遅延
- 51. 配信が止まる
- 70. 熊本市のサイトの場合
- 72. 速さの秘密
- 77. Yahoo! Japanの場合
- 84. Spelldataの場合
- 86. 300KBでこの秒数
- 87. ウォーターフォール図
- 92. 対策1： 有事の際には、有事用サイトに切り 替える – HTML+CSSを基本にする – 動的ページを止めて、静的ページへ移行する – どうしても必要な場合のみ、画像を入れる – 1ページの容量を100KB以下にする – 状況に応じて、50KBまで減らす – アクセス解析など、一切のサードパーティーコンテンツを外す – SNSのボタンは遅延要因なので外す – どうしてもボタンを付けたい場合は、自作にしておく
- 94. 対策2: サーバの負荷をどこかに受けてもらう – AWS S3のようなオンラインストレージ – 10TBの転送量があったとしても、月3万円強で済む – 最初の1GB転送量で、0.033ドル（3.3円） – 使えば使うほど安くなる – CDNの活用 – Fastlyお勧め – ディベロッパーアカウントは月5000円から使える – チャージしておいて、緊急時にだけ使うという使用方法もあり
- 95. 対策3: 情報伝達経路のマルチチャネル化 – 全ての情報伝達経路をインターネットにしない – 身の安全を確保した市民は、できるだけ、携帯網を使わないようにしてもら う – 避難勧告や救助情報、支援情報など、今、目の前の危機に対処する人の ために、携帯網の回線を開けてあげる、という事を市民に協力依頼する重 要性 – インターネットでも、携帯網よりは、有線回線網を勧める – TV、ラジオなどのマスメディアを通じた協力依頼 – 連絡網の全てをインターネットに依存しない仕組みづくり – 主要な連絡係には、携帯網を使った通信で、連絡係から避難所の人々には 口頭で伝える、伝言板で伝える、館内放送で伝えるなど – 既存の仕組みを上手く活用する – 電話会社や携帯会社、GoogleやFacebookなど、各社が提供している災害時の情報伝 達網を活用する
- 96. 市民のITリテラシーを上げる重要性 – 今後、災害が増えることはあっても、減ることは無い – 各種の状況がそれを示唆している – 市民ひとり一人のITリテラシーを上げる事は、災害から身を守ること に直結する
- 97. 「一見どうみえようとも、それはつねに人の問題 である。」 ― G・M・ワインバーグ – 問題を、広義の意味でのハード ウェアのせいにして、ハードウェ アで解決しようとしてはいけな い。 – 問題は、広義の意味でのソフト ウェア、人に依存する問題であ る。 – 人にフォーカスしましょう。 我々、人間は、学ぶことができ るのです。
- 99. 価値ある情報＝理解できる情報を 高速に配信する – 1時間に100ミリの雨量 – 分からない – 1時間で6畳（約10㎡）の部屋に1トンの水が貯まるぐらいの量 – 凄さが分かる – 1時間で6畳の部屋に、牛乳パック1000本分の水が貯まる – 逆に軽くみられるかも… – 1時間で6畳の部屋に、10㎝の高さの水が貯まる – まぁ、それくらいと思われてしまうかも…
- 100. Q&A