Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

2.480 Aufrufe

Veröffentlicht am

自治体のWebサイトは平時よりも緊急時の方が表示速度や可用性が高度に求められ、特に、災害時の自治体のWebサイトの情報発信は、時に人の命に関わる事もあります。 昨今の地球温暖化の影響と社会インフラの老朽化に伴い、今後ますます住民や、他の公共組織や民間組織などの関係各組織に滞りなく情報発信できるかどうかが大きな鍵を握ります。
では、どのように緊急時のWebサイトの表示速度や可用性を担保すれば良いかについては、実際のところ、殆どノウハウが公開されていません。
このセッションでは、緊急時に起こりうる突発的なアクセスの急増に耐えつつ、かつ高速に重要な情報を配信するための、表示速度と可用性の設計や運用について概要を解説します。

  • Als Erste(r) kommentieren

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

  1. 1. MTDDC Meetup TOHOKU 2016 自治体Webサイトに求められる Webサイトパフォーマンスの要件 災害危機に対応できる表示速度と可用性 2016年6月25日 竹洞 陽一郎 yoichiro.takehora@spelldata.co.jp
  2. 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 … 日本代表
  3. 3. 株式会社Spelldata
  4. 4. Webサイトパフォーマンス品質評価証明書
  5. 5. Webサイトパフォーマンスについて
  6. 6. Webサイトパフォーマンス管理の基本
  7. 7. 統計学を基礎から学ぶ! 中西塾 第一期 2014~2015
  8. 8. 統計学を基礎から学ぶ! 中西塾 第二期 2016/4~
  9. 9. 「第7章 コンテンツの解析」 配信品質と情報品質
  10. 10. Project ICHIGANのネットワーク設計を担当
  11. 11. 今日、お話する内容 – 自治体サイトの重要性の変化 – 有事の際に繋がる自治体サイトにするために – 計測データから見る緊急時の自治体サイトの理想 – 有事の際の自治体サイトの対策 – おまけ ― 「データ」ではなくて、「情報」を配信する
  12. 12. 自治体サイトの重要性の変化 無事よりも有事に注目される、その存在意義
  13. 13. 2014年10月31日 横浜市総務局危機管理室
  14. 14. 2015年9月10日 仙台市
  15. 15. 2016年4月14日 熊本県
  16. 16. 変わりゆく自治体Webサイトの役目
  17. 17. 従来の災害情報のチャネル – TV – ラジオ – 広報車 – 防災無線スピーカー – 町内会 昨今の災害情報のチャネル – Webサイト – Twitter – 災害速報メール – TV – ラジオ 災害情報伝達のチャネルの変化 単純にインターネットが普及しただけではなく、従来のメディアでは、 「災害の局所化」=「対象情報の複雑化・断片化」に対応できないと いう背景がある
  18. 18. 災害の局所化 – 都市圏への人口集中が激しくなっている – 都市基盤の整備では、経済的側面から、全てを強化することはできない – 地下街の開発→地下への浸水の問題 – 超高層建築物→想定していない新しい側面が生み出す、新しい災害 – 人口の現象と高齢化社会に伴う限界集落の問題 – 集落の「集団」の力で対応できなくなって、災害化してしまう – 森林の持つ多面的機能の持続性維持が損なわれつつある – 森林の荒廃に伴う、保安林としての機能不全 – 社会インフラの老朽化 – 地球温暖化の影響の加速
  19. 19. 社会インフラの老朽化
  20. 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%
  21. 21. 日本列島を襲う「水道管破裂」 老朽化の波が押し寄せる 年間2万5000件の事故 http://news.yahoo.co.jp/feature/167
  22. 22. 地球温暖化 http://www.climate-lab-book.ac.uk/files/2016/05/spiral_optimized.gif
  23. 23. ゲリラ豪雨(局地豪雨)―渋谷の例
  24. 24. 竜巻発生の増大化
  25. 25. 従来のメディアによる災害情報 1対1の関係
  26. 26. 現在のメディアによる災害情報 Webへの誘導 「詳細は、各自治体のWebサイトで確認してください。」
  27. 27. 従来のマスメディアの強みと弱み – 出来るだけ多くの人々にとって、興味があるであろう、共通の情報を 配信することが出来る点が強み。 – リアルタイムで変化する状況を配信するのは弱い。 – 編集する必要性 – 興味を持つであろう人々や、情報の内容が多様化すると弱い。 – 対象地域が色々と異なる – 特定の地域の人々のみが対象 – 短い期間だけの出来事
  28. 28. TVで、どこまで細かい情報を伝えられるか?
  29. 29. 災害の局所化が進む中で、 自治体Webサイトが果たすべき役割は大きい – きめ細やかな情報の提供 – 迅速な情報の提供 – 信用できる情報の提供 – 災害対応に強い自治体は、自治体そのもののブランディング化に繋 がる – 子育て支援自治体 – リモートワーク支援自治体 – スタートアップ支援自治体 – 「災害対応に強い自治体」 – ハードウェア面(モノ)ではなく、ソフトウェア面(ヒト)を見て考える – ハードウェア(箱モノ)に依存する不動産価値ではなく、ソフトウェア(共同体、体制、文 化)に基づく不動産価値が、自治体の価値を高める
  30. 30. 有事の際に繋がる 自治体サイトにするために ネットワークの出口を考えておく
  31. 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 携帯網のネットワークトポロジー
  32. 32. インターネットから 携帯ネットワークを経由してスマートフォンへ
  33. 33. 電波は有限資源 – NTTドコモの800MHz帯の例 – 総務省から15MHzの幅をもらっている – それを12.5KHz幅で区切る – 15MHz/12.5KHz = 1200チャネル – 7つのグルーピングを作るとすると、各基地局は 1200/7≒170チャネルとなる。 – 四色定理から、4つのグループをつくれば十分だが、それでは、 基地局設計がギチギチになってしまうので、ゆとりを持つために7 つのグループに分ける
  34. 34. 電波の「傘」(周波数)をぶつからないように置いて、 雨に濡れない(電波が途切れない)ようにして歩く
  35. 35. 四色問題→四色定理 – 隣接する領域が異なる色にな るように塗り分けるには、何色 あれば良いのか? – 1976年に、ケネス・アッペルと ヴォルフガング・ハーケンが四 色定理をコンピュータを使って 証明
  36. 36. 郊外の基地局配置 1つの円で20~30Kmをカバー。 その分、電波が強い。 色の違い= チャネルのグループの違い。 郊外の携帯網の基地局設計
  37. 37. 都市部の基地局配置 1つの円で200~300mをカバー。 その分、電波が弱い。 都市部の携帯網の基地局設計
  38. 38. ソフトバンクの「マイクロセル化」
  39. 39. 制約の多いモバイルネットワーク – 電波干渉という問題 – ユーザがそこに多く居るからと言って、電波塔(基地局)は増やせない – 基地局を乱立するとどうなるか? – “Dirty WiFi”と同じ状況に – 電波の「谷間」~基地局と基地局の中間点 – 「繋がる」事と「通信できる」事は、違う – アンテナの表示が5本中5本立った! → 電波強度が十分というだけ – 携帯基地局は、混雑するとネットワークを守るためにパケットを意図的にド ロップする – レイテンシの問題 – モバイルネットワークのレイテンシは3Gで100~200ms、4Gで40〜60ms 2016年6月25日 39 ©2012 Keynote Systems, Inc..
  40. 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. 41. ありがちな勘違い – サーバが高速化されれば良い – 出口の混雑の問題は解決しない – CDNを入れれば良い – 出口の混雑の問題は解決しない – 軽量化すれば良い – 皆さんが想像している以上の軽量化が必要 – キャッシュを効かせればよい – ブラウザキャッシュ? – サーバサイドキャッシュ? – 状況の変化が見通せるならどうぞ。普通は怖くてできない。
  42. 42. 入口も出口も、双方、考える ここも大事 こっちはもっと大事
  43. 43. 災害が発生している地区と無事な地区が 同じ基地局内に存在する場合 半径2Km 災害発生地区 無事な地区 通信帯域を必要としているのは、どちらなのか?
  44. 44. 熊本の震災でのLINE通話10分無料の問題 災害時、通信帯域は貴重。人命をも左右する。
  45. 45. 社会心理学者レヴィンの概念式 B = F(P・E) B=行動、P=人の状態、E=環境 人の行動は、その人の状態と環境に よって決まる
  46. 46. 被災者と非被災者の「災害」状態の違いが 引き起こす行動の違い 半径2Km 災害発生地区 無事な地区 通信帯域を必要としているのは、どちらなのか? 非被災者は、災 害情報を「消費」 する 被災者は、災害 情報を「生産」す る
  47. 47. 計測データから見る 緊急時の自治体サイトの理想 計測データが、理想の容量を教えてくれる
  48. 48. 仙台市のサイトの場合
  49. 49. 散布図 ダウンロード完了時間 ― デスクトップ www.city.sendai.jp
  50. 50. 読み込みの遅延
  51. 51. 配信が止まる
  52. 52. ヒストグラム ダウンロード完了時間 ― デスクトップ
  53. 53. ヒストグラム 表示開始時間 ― デスクトップ
  54. 54. ヒストグラム 表示完了時間 -デスクトップ
  55. 55. 散布図 ダウンロード完了時間 ― スマートフォン www.city.sendai.jp
  56. 56. ヒストグラム ダウンロード完了時間 ― スマートフォン
  57. 57. ヒストグラム 表示開始時間 ― スマートフォン
  58. 58. ヒストグラム 表示完了時間 -スマートフォン
  59. 59. 散布図 ダウンロード完了時間 ― デスクトップ www.city.sendai.jp/bousai/index.html
  60. 60. 画像が足を引っ張っている 青色は、読込時間を指す。 つまり、全般的に、ディスクアクセスの遅延が目立つ
  61. 61. 画像配信の遅延~待機時間 橙色は、待機時間を指す。 つまり、全般的に、CPUやメモリの不足が目立つ
  62. 62. ヒストグラム ダウンロード完了時間 ― デスクトップ
  63. 63. ヒストグラム 表示開始時間 ― デスクトップ
  64. 64. ヒストグラム 表示完了時間 ― デスクトップ
  65. 65. 散布図 ダウンロード完了時間 ― スマートフォン www.city.sendai.jp/bousai/index.html
  66. 66. GoogleアナリティクスのSSL接続が足を引っ 張る オレンジ色の箇所はSSL。Googleアナリティクスは、いつも遅延要因。
  67. 67. ヒストグラム ダウンロード完了時間 ― スマートフォン
  68. 68. ヒストグラム 表示開始時間 ― スマートフォン
  69. 69. ヒストグラム 表示完了時間 ― スマートフォン
  70. 70. 熊本市のサイトの場合
  71. 71. 散布図 ダウンロード完了時間 ― スマートフォン
  72. 72. 速さの秘密
  73. 73. ウォーターフォール図 ― スマートフォン
  74. 74. ヒストグラム ダウンロード完了時間 ― スマートフォン
  75. 75. ヒストグラム 表示開始時間 ― スマートフォン
  76. 76. ヒストグラム 表示完了時間 ― スマートフォン
  77. 77. Yahoo! Japanの場合
  78. 78. 散布図 ダウンロード完了時間 ― スマートフォン
  79. 79. 400KBを超えたら、もうダメ… エラーもある…
  80. 80. 接続エラー 接続エラーが発生すると、足を引っ張る
  81. 81. ヒストグラム ダウンロード完了時間 ― スマートフォン
  82. 82. ヒストグラム 表示開始時間 ― スマートフォン
  83. 83. ヒストグラム 表示完了時間 ― スマートフォン
  84. 84. Spelldataの場合
  85. 85. 300KBでこの秒数
  86. 86. ウォーターフォール図
  87. 87. ヒストグラム ダウンロード完了時間 ― スマートフォン
  88. 88. ヒストグラム 表示開始時間 ― スマートフォン
  89. 89. ヒストグラム 表示完了時間 ― スマートフォン
  90. 90. 有事の際の自治体サイトの対策 具体的処方箋
  91. 91. 対策1: 有事の際には、有事用サイトに切り 替える – HTML+CSSを基本にする – 動的ページを止めて、静的ページへ移行する – どうしても必要な場合のみ、画像を入れる – 1ページの容量を100KB以下にする – 状況に応じて、50KBまで減らす – アクセス解析など、一切のサードパーティーコンテンツを外す – SNSのボタンは遅延要因なので外す – どうしてもボタンを付けたい場合は、自作にしておく
  92. 92. 携帯網の可用性やパフォーマンスでは、 上り路線だけではなく、下り路線を考えないといけない
  93. 93. 対策2: サーバの負荷をどこかに受けてもらう – AWS S3のようなオンラインストレージ – 10TBの転送量があったとしても、月3万円強で済む – 最初の1GB転送量で、0.033ドル(3.3円) – 使えば使うほど安くなる – CDNの活用 – Fastlyお勧め – ディベロッパーアカウントは月5000円から使える – チャージしておいて、緊急時にだけ使うという使用方法もあり
  94. 94. 対策3: 情報伝達経路のマルチチャネル化 – 全ての情報伝達経路をインターネットにしない – 身の安全を確保した市民は、できるだけ、携帯網を使わないようにしてもら う – 避難勧告や救助情報、支援情報など、今、目の前の危機に対処する人の ために、携帯網の回線を開けてあげる、という事を市民に協力依頼する重 要性 – インターネットでも、携帯網よりは、有線回線網を勧める – TV、ラジオなどのマスメディアを通じた協力依頼 – 連絡網の全てをインターネットに依存しない仕組みづくり – 主要な連絡係には、携帯網を使った通信で、連絡係から避難所の人々には 口頭で伝える、伝言板で伝える、館内放送で伝えるなど – 既存の仕組みを上手く活用する – 電話会社や携帯会社、GoogleやFacebookなど、各社が提供している災害時の情報伝 達網を活用する
  95. 95. 市民のITリテラシーを上げる重要性 – 今後、災害が増えることはあっても、減ることは無い – 各種の状況がそれを示唆している – 市民ひとり一人のITリテラシーを上げる事は、災害から身を守ること に直結する
  96. 96. 「一見どうみえようとも、それはつねに人の問題 である。」 ― G・M・ワインバーグ – 問題を、広義の意味でのハード ウェアのせいにして、ハードウェ アで解決しようとしてはいけな い。 – 問題は、広義の意味でのソフト ウェア、人に依存する問題であ る。 – 人にフォーカスしましょう。 我々、人間は、学ぶことができ るのです。
  97. 97. おまけ 「データ」ではなくて、 「情報」を配信する 高速に「データ」を送れば、それで良いわけではない。高速に「情報」を送る。
  98. 98. 価値ある情報=理解できる情報を 高速に配信する – 1時間に100ミリの雨量 – 分からない – 1時間で6畳(約10㎡)の部屋に1トンの水が貯まるぐらいの量 – 凄さが分かる – 1時間で6畳の部屋に、牛乳パック1000本分の水が貯まる – 逆に軽くみられるかも… – 1時間で6畳の部屋に、10㎝の高さの水が貯まる – まぁ、それくらいと思われてしまうかも…
  99. 99. Q&A

×