2008年12月 5日
21.大学における電子メールサービスのアウトソーシング [パネル討論]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)21.大学における電子メールサービスのアウトソーシング
コーディネータ：中村素典（国立情報学研）
パネリスト：松村芳樹（一橋大）・井村保（中部学院大）・下園幸一（鹿児島大）
・大学における電子メールシステムの運用管理を取り巻く状況の変化
・予算削減
・環境問題対策
・定員削減
・ユーザーサポートのコスト増
・求められるサービス水準の上昇
・情報セキュリティポリシーの導入
・アウトソーシングサービスの登場
・Google Apps Education Edition 2006.10 一橋大学
・Windows Live@edu 2007.4 鹿児島大学
・Yahoo!メール Academic Edition 2007.12 中部学院大学
・それぞれのサービスを利用している3大学から
・各大学の事例紹介
・以前のシステムの概要、問題点
・アウトソーシングの検討にあたっての課題
・実際に導入したアウトソーシングの形態、導入に伴う変化
・解決された課題、残された課題、新たな課題
・GoogleApps 導入について
・一橋大学
・4学部4430名、大学院2046名、経済研究所
・学内のメールサービス
・総合情報処理センター、教育・研究用メール、2008.4から学生だけGoogleAppsに移行
・事務局・事務部、事業用メール、一般職員
・研究科・研究所
・これまでのメールシステム
・1994年、研究用WSでSMTPを運用開始、希望者のみユーザ登録、100名程度
・1999年、教養系PC演習室を統合、全学生がサービス対象に8000ID
・2003年、専用サーバに移行、WebMail（courier-imap+Active!mail）、LDAP認証統合、SPAM増、サーバ負荷増
・2006年、サーバ更新
・2007年、qmail → Postfix
・2008年、学生分（7200ID）をGoogleAppsへ
・既存システムの問題点
・インフラ化によるユーザの期待と現実の乖離、保守時間、夜間休日の障害対応
・SPAMによるqueueの増加とストレージの圧迫
・UIやマニュアルの整備が追いつかない、社会科学系のユーザに分かるもの、多言語化
・技術継承の問題
・上記問題をお金で解決できない、アプライアンス・ホスティングだと1ID=200-500円／月、今できてるのになぜ新たな費用が発生するんだ！！
・メールサービスに対する要件
・自ドメインが使える
・他システムとおなじID・PW
・SPAM対応
・インタフェースの充実
・無停止
・追加経費無し
・GoogleAppsの利点
・Provisioning APIによるユーザ管理
・他言語UI
・SPAMフィルタ
・Google Documents, Calendar
・Education Editionならこれらの機能が当面無料
・2007年には海外でサービスが具体化していた、日大も導入していた
・導入までのスケジュール
・2007年6月からはじめる
・GoogleApps導入の懸念
・広告の表示、Education Editionは表示しなくてもよい
・利用動向をマーケティングに転用されること
・その他、規定が合衆国連邦法に基づいている点、某国の情報統制に荷担しているGoogleは云々かんぬん
・古いメールデータの移行
・旧Maildir→演習質PCのメーラー（Thunderbird・Outlook）→Google Email Updater→GoogleApps、これを各自にやらせた
・認証系連携
・WebUIでパスワード変更とかをしたときに、GoogleApps側にも反映
・利用実績
・登録対象7200ID
・GoogleApps導入効果
・メールボックスの増量、200MB→7GB
・メール利用相談件数の減少
・法廷電気点検中も稼働
・いまのところ賞賛も苦情もあまり聞かれない
・新たな課題
・ログが取れない、クラウドコンピューティングの弱点
・障害発生に関する情報がない、、、
・気がつけば仕様変更、、、
・無償サービスが終了したらどうする、、、
・これまでに発生した問題
・1部のプロバイダでgoogle.comが引けない、4/28 1時間程度、大学からの接続が全滅
・某MLサービスからメールが届かないことがある、SPAMがらみで同時接続制限？
・共有PCで他人のGmailが読めてしまう、利用者に周知徹底ですな
・今、某国にいるのだがGoogleAppsに繋がらない、、、オリンピック前後、、、
・今後の展開
・教職員への展開
・リテラシーの問題、成績やパスワードのやりとりが平気で、、、、研究用途に限定すればすぐにでもホスティング可能、有償サービスも含めて検討すべき
・卒業生への展開
・国際的研究拠点に貢献、ユーザー管理はどうしよう？
・Yahoo!メールAcademic Editionの導入について
・中部学院大学
・岐阜県
・関キャンパス、各務原キャンパス
・1997年開学、その前は短大
・当時はSINET：64kbps/専用線
・2001年1.5M、2004年100Mx2
・キャンパス間専用線、100M
・2008年学生1800人、職員250人
・岐阜情報スーパーハイウェイ（SHW）、岐阜県が敷設した光ファイバーを無償で
・メール環境
・1997年、UNIXサーバ（POP/SMTP）教職員対象
・1999年、学生対象、Windowsサーバ
・2004年、Webmail対応化、教職員・学生対象
・2006年から2007年：アウトソーシング、教職員 Mail Luck!、学生対象 Yahoo!メールAE
・アウトソーシングの背景
・落雷による停電・瞬電が多い
・専門的な技術職員が不在で、維持管理が大変
・利用頻度増加で、サービス停止が困難な状況
・受信容量の大規模化、高機能なサーバ、、、対応に多額の費用が必要
・以前のシステム概要
・Sebdmailサーバ、年度初めにアカウント作成
・ファイルサーバ、メールボックス5MB
・Active!Mail 2003の追加
・今回のリプレースにおける検討
・現状の問題点
・容量が少ない
・メール転送が不可、確実に学生への連携を行う事への対応が必要
・ネットワークのメンテナンスや障害時にサービス停止
・アウトソーシングにおける検討課題
・サービス停止の回避
・運用コスト削減
・セキュリティ
・使いやすさ
・Yahoo!メールからの提案
・学生の個人情報をあらかじめ提出が不要
・所定の手続き後のみ利用可能
・メールデータを二重で保護
・フリーメールとは別にYahoo!メールAE提供用システムを構築して運用
・無料
・アクティベーションの仕組み
・IDは連携、パスワードは個別で設定
・Webでユーザ認証→アクティベーション
・移行スケジュール
・ドメインを全面切り替え
・サーバ切り替え前1ヶ月
・DNS切り替えによるサーバ変更
・旧サーバを、保管用として暫定維持
・改善点
・メール容量が5MBから1GBへ、容量を気にすることなく、メールシステムの設置・維持費が大幅に削減
・メール転送が可能に、携帯電話へのメール受信通知なども可能、通知するメールのフィルタリングも可能
・ASPで24時間365日サーバ管理されるため、サービス停止が基本的には発生しない
・利用状況
・YahooのWebサイトからもログイン可能
・現在は通学生の未利用対象、960人
・アクティベーション情報は毎晩通知
・今後は通信教育課程への配布を行う予定、ActiveDirectory連携がネック
・その他、改善点、課題
・担当者負担の軽減、業者対応等が不要、パスワード再発行対応不要
・携帯アドレス変更時に、通知アドレス更新を忘れ、着信通知が不達になったり、学生は携帯アドレスを簡単に変更しちまう
・アクティベーション完了前はメールが受信されない
・Yahoo!IDを既に持ってる人は、別のIDを持たなきゃいけない、逆におなじインタフェースを使ってる弊害か？
・鹿児島大学学術情報基盤センター「生涯メールサービスについて」
・Windows Live@Edu
・既存の環境
・入学時に全学生にセンター利用証を配布
・学部生9400名、大学院生1800名
・センター利用証で利用できるサービス、センター管轄のPC、センター提供のメールサービス、オープンネットワーク
・Webメールサービス、Active!mail2003を利用、ほとんどの学生が「情報活用基礎」授業で利用する
・50MB、POP、メールエイリアス、転送可能
・卒業後1ヶ月で全削除
・既存環境の問題点
・運用上、大規模なファイルサーバとメールサーバが必要
・メール処理の遅延
・システム更新時の移行が煩雑
・新メールサービスに愛する要求
・大規模な容量
・Webメール、多言語対応
・センター利用証とのID連携
・大学独自のドメインが利用可能
・携帯電話からの利用
・耐高負荷
・卒業後も利用可能
・Windows Live@Edu
・独自ドメインでマイクロソフト社が提供し画居る各種サービスを無償で提供
・メール、スケジュール、メッセンジャー、ブログ、ネットワークフォルダ、モバイル、お知らせ、ドキュメント共有、SNSみたいなやつ
・生涯メールサービスの運用方針
・センター利用証IDとの連携
・メールドメイン名は@kadai.jp
・入学時から卒業後も利用可能
・卒業生に対して定期的に大学の情報を提供
・独自のロゴとメニューを追加
・広告欄がない
・システムの構築
・Microsoft ILM2007に夜ID連携
・学生以外は広告が付く
・情報は鹿児島大からMSへの一方通行
・パスワード連携
・センター利用証に初期パスワード記載
・PC利用とWindows Live利用時の初期パスワードは同一
・変更後パスワード、PCとWindow Liveパスワードは連携しない
・運用状況
・2008年3月卒業生と、2008年4月～の在学生が利用可能
・利用統計は取れていない、マイクロソフトに要望は出してる
・使い方などに関する問い合わせもほぼ無い
・生涯などに愛するマイクロソフト社のサポート、毎日のようにメールが来る
・2009年1月末までには、既存のメールシステムが利用できる、そっちを使ってるのかなぁ
・2008年4月入学生は利用している（はず）
・問題点
・Windows Live Hotmail自体
・電子メールの転送設定を行うと、メールサーバ側に残らない
・ID作成後180日以内に利用者による初期設定が行われないと、メールボックスが削除される
・360日間利用がないとメールボックスが削除、卒業生は180日
・運用上の問題
・卒業生が「パスワードを忘れた」と行ってきたときの対応
・卒業→入学の際のIDの継続
・今後の課題
・利用者任意のメールアドレスを利用できるようにする
・既存メールサーバからの移行の促進
・Hotmail以外のサービスの利用促進
・ポータルサイトなど、センターシステムとの融合
・他のサービスの検討は？
・鹿児島大学：Googleのサービスはみんな使ってるんじゃないか？ とか、メール以外のサービスが魅力的だった
Q.後ろ向き的な選択のような気が、、、執行部にどんなプレッシャーをかけるのか？
A.一橋：これからの課題、、、説明して分かってもらう前に、執行部が変わってしまうかも
中部学院：就職活動の際にyahoo.co.jpよりはac.jpからのメールの方がいい、今はその段階
鹿児島：動いてる、位の認識。卒業生に対するコネクションがあるというのが大きい
Q.もうちょっといいソリューションを誰か作ってないかなぁ？ っていうか、みんなで作っちゃったらどうだろう、xxxのあたりをなんとかして、ぶつぶつ、、、
A.、、、（まとめるのが大変そう）
金沢大学の大野先生が激しい提言を、、、っていうか、ここに来てる先生方、すさまじいなって、よく考えたら中村先生って中村素典先生じゃん、、、神様みたいなー
投稿者 ymkx : 2008年12月 5日 17:42 |
20.ALGを用いたマルチホーム環境における自組織宛メール配送の動的経路選択手法 [セッション6: ネットワーク運用]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)ALGを用いたマルチホーム環境における自組織宛メール配送の動的経路選択手法
○金勇・清家巧・岡山聖彦(岡山大)・中村素典(国立情報学研)・山井成良(岡山大)
・電子メールの安定的な運用が重要
・マルチホームネットワーク
・IPレベルの対応方法
・BGP
・利点：ネットワーク層でマルチホームネットワークに対応
・欠点：ネットワークの状態を考慮しない、他組織との連携が必要になる
・アプリケーションレベルの対応
・ALG
・導入・運用・管理が容易
・電子メール配送経路の動的選択によるマルチホームネットワークの有効利用
・DNSラウンドロビンによるトラフィック分散
・動的なトラフィック分散が出来ない
・ネットワークの状態を考慮する
・送信者がメールを送る差異のDNS問い合わせに着目
・DNSの仕組みでは、要求と応答が一対一に対応
・DNSを異なる経路に毎に設置、それぞれのメールGWを優先度を高めてmxに登録
・んー、これ、わかるんだけど、そんな単純な話しなのかなぁ？
・DNS Proxy
・ふーん、両経路のDNSに応答させて、早い方が先に問い合わせもとDNSに戻るからね
・実験結果
・2秒間の遅延を与えると確実に、遅延してない方を選択、当然だけど
・FTPトラフィックを発生させると、9割近く空いてる方を選択。残りの1割ってのはどういう状況なんだろうね
・実ネットワーク環境での実験結果
・遅延の小さい経路を優先
・今後の課題
・実ネットワークでの性能評価（BGPとの併用）
・他のアプリケーションサービスでの検討
・送信元IPアドレスの詐称拒否に対する対策
Q.遅延と帯域を同列で扱っている点について
A.遅延は距離の遠近、帯域は、、、同列に扱われるものかどうかは、、、確実に同列ではないですよね、近くて細い、遠くて太い、今回の実験ではそこまでやっていない。パケットを連続で出して、細いところの遅延をチェック
Q.mxレコード及びAレコードで、mxを選択したのはなぜ？
A.Aレコードを弾いて失敗すると終わってしまう、mxレコードを選択
投稿者 ymkx : 2008年12月 5日 15:47 |
19. 従来端末に対する移動透過通信支援方法とそのプロトタイプ実装 [セッション6: ネットワーク運用]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)19. 従来端末に対する移動透過通信支援方法とそのプロトタイプ実装
○関顕生・西村浩二・相原玲二（広島大）・前田香織(広島市大)
・キャンパス内での移動通過通信
・IPアドレスを変えたくない要求
・移動透過通信の必要性
・移動透過通信の既存研究
・Mobile IPv4/v6
・Proxy Mobile IPv6
・既存技術の組み合わせ解決
・PortGuard
・MAT、移動透過インターネットアーキテクチャ、一時的アドレスと恒久的アドレスの対応表の管理
・MAT-PortGuard
・PortGuartd（利用者認証＋NAT）＋MR
・モバイルアドレス割り当て
・従来端末に変わってアドレス変換
・IMS
・MAT-GW
・もー、ちんぷんかんぷん、やることは分かるんだけど
・トンネル化の影響
・ショートパケットほどオーバーヘッドが大きい
・ビデオ会議システム、VoIPアプリケーション、遅延を小さくするためにショートパケットを使用している
投稿者 ymkx : 2008年12月 5日 15:17 |
18. 利用者認証機能を備えた大規模キャンパスネットワークの性能評価 [セッション6: ネットワーク運用]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)18. 利用者認証機能を備えた大規模キャンパスネットワークの性能評価
○近堂徹・田島浩一・岸場清悟・大東俊博・岩田則和・西村浩二・相原玲二（広島大）
・従来型キャンパスネットワーク
・部局単位でサブネット管理
・目的や要求に応じて比較的自由な運用
・部局へのネットワーク管理負担の増加、管理者の代替えなども多く発生
・セキュリティインシデントが多発、ウィルスやクラックに対する追跡把握
・利用者認証を軸とする全学管理のネットワークへ
・キャンパス情報ネットワーク HINET2007
・主要3キャンパス、付属学校、小規模沿革部局
・教員約1800人、職員3300人、学生15000人
・フロアスイッチ約400台（14000ポート）を全学整備
・フロアスイッチまでを管理、それ以下を部局で管理
・全学的な一元管理体制、各フロアに設置するスイッチまで全学管理
・個別ファイアウォールの提供、核教員大意でのファイアウォール（約2000個）、全学ファイアウォールとも併用
・VLANによる柔軟なネットワーク、キャンパス間での研究室ネットワークにも対応
・全ての場所で機器接続に利用者認証
・利用者認証に対する要件
・ネットワークインフラとしての認証ネットワーク
・多様な機器に対応、複数OS混在、PC以外のネットワーク機器も認証
・既存の研究室内ネットワークとの親和性、ダムハブなども多数存在
・認証後でもワイヤスピードを確保、認証を入れることに夜パフォーマンス低下はNG
・最寄りのフロアスイッチにて利用者・機器認証、WebとMac認証を行う
・短時間での一斉認証要求への対応
・共同利用施設や事務職員用端末、朝の15分間で600台が稼働、100台からの同時認証を30秒以内で処理出来ることを条件
・利用者認容の概要
・Web認証、スイッチに中間CA証明書、初回接続時に認証ページ
・Mac認証、事前登録
・認証サーバ
・Web認証（バックに全学電子認証システムLDAP、ゲストアカウント用LDAP）、MAC認証（ホスト登録装置、Mac認証用Radius）、DHCP、それぞれ駆動系とホットスタンバイ
・DHCOサーバのIPアドレス払い出し性能評価
・450台のDHCPアドレス取得要求に対して最大0.12秒以内で処理が完了
・Radius認証処理の性能評価
・600台からのRADIUS認証要求に対して1秒以内に処理可能
・認証スイッチの一斉確認処理性能評価
・数セッションの同時認証では1秒
・100セッションの同時認証でも最大で23秒
・8時20分から35分の間に591台の認証処理を実現
Q.Web認証の時間、23秒って？実データ？
A.実データ、100台が同時に的なパターンです
Q.どうやって100台のリクエストを出したの？ 短い間隔って？
A.37台のクラスタでPortalServerからリクエストを分散実行させるシステムを利用、コマンドラインのwget。時間については100台で1秒以内（事前別測定）
Q.34台で100台をエミュレート？
A.1台で複数のリクエストを発行
投稿者 ymkx : 2008年12月 5日 14:44 |
16.「学友を生涯の宝に」人脈形成支援型ネットワークシステムの展望 [招待講演2]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)16.「学友を生涯の宝に」人脈形成支援型ネットワークシステムの展望
児玉太郎（ヤフー）
・1999年入社
・ソーシャルネット事業部 企画部長
・440億pv/month
・アクティブID、2257万、、、
・インターネットポータル事業
・150のサービス
・コンテント列（トップ左サイド）の奪い合い
・一覧にも載らないサービスが、、、
・従来のインターネットサービス
・Web1.0
・サイトが縦割りになっている
・トップページから下る形でコンテンツを閲覧する作り
・ヤフーもその作りだった、今でもその作りのコンテンツは多い
・情報がエディトリアル（編集コンテンツ）である
・人の手を使ってコンテンツが編集されている
・情報提供元から配信される情報を整理して表示
・情報への到達手段が能動的である
・サイトにたどり着くための手段は検索
・近年の進化
・縦割りのサイト作りが、より便利に、簡単に
・Web2.0的サイト開発手法
・一言で言うと「色々組み合わさってる」、マッシュアップ、Web API
・Yahoo pipes、これ面白いなぁ
・集合知を情報の核に
・結果情報が増えたため、情報到達手段として「受動的」の登場
・データ分析型レコメンドエンジン、Amazonとか
・ソーシャルレコメンドエンジン、人脈を活用した情報到達手段の提供（自分の人脈による口コミ）
・プラットフォームの多様化
・機能毎の役割分担がインターネット業界全体で進んでいる
・様々なプラットフォーム、コンテンツ、マネタイズ、システム、データ（アイデンティティ、人脈）
・人脈プラットフォームの可能性
・人脈プラットフォーム
・誘導プラットフォーム（トップ、検索）、認証プラットフォーム（Yahoo id）、課金・決済プラットフォーム(ウォレット)、広告配信プラットフォーム
・ソーシャルプラットフォーム
・人格（アイデンティティ）プラットフォーム
・人脈伝播（バイタリティ）プラットフォーム
・人格の確立、自分が誰なのか
・人脈の管理
・人脈伝播網の活用
・人脈フィルタリング、増えすぎてくると整理が必要
・人脈アクセスコントロールリスト（ACL）、自分の情報の公開を制御
・人脈伝播（バイタリティ）プラットフォームの技術
・ヤフーの場合、ユーザ数が膨大、2000万ID、、、
・バイタリティプラットフォームは、全ユーザ分のあらゆるアクションデータを蓄積
・ユーザが、自分のつながりの新着確認ページにアクセスすると、人脈プラットフォームからつながりを挽いてくる
・挽いてきたつながりで、バイタリティプラットフォームに「検索」をかけ、結果を表示する
・スケールが恐ろしい、、、ちょっと逃げ出したくなるかも、エンジニアとして、、、
・学友を生涯の宝に
・情報格差社会と知識の平均化
・情報格差社会、インターネットの活用法を知ってる人と知らない人、たくさんの情報の中から、目的の情報にたどり着ける人とたどり着けない人
・人脈がもたらす情報への効率的な導き、レコメンドとフィルタリング
・知識の平均化、新聞の斜め読みをしなくなった、本を読まなくなった、便利な反面、おなじものを同じように知ることによる知識の平均化が深刻
・人脈がもたらす知識の多様化、が必要なのでは
・学友を生涯の宝に
・学友は、生涯の宝になる人脈の種、学校は学びを得るためだけでなく、人脈を形成するための場である。ここでの人脈形成が「情報格差社会」の中で力強く生きる糧になる
・学校による人脈形成支援の必要性
・希薄な人脈形成欲求
・海外では日本に比べて母校に対する忠誠心や愛が強い
・特に、大学を、就職するためのプロセスだと考えている学生が多い
・同級生よりもバイト仲間、つまり友達しか作れていない
・国際競争力の低下
・少子化、国際競争力を保つためには、つながりを強化し助け合うべきネットワークの形成が不可欠
・ヤフーのオープン化戦略
・縦割りの限界
・餅は餅屋的に
・ヤフーのプラットフォームの開放、独自の専門サイトも使えるように
・
・学内システムの共通プラットフォーム化
・学校毎に行われる独自システム開発、、、
・せめて、人脈形成支援システムなどでは、学校間のシステム連携が必須
・人脈は生涯を通じて苦労なく管理できるべきであり、在学中しか活用できない人脈形成支援システムでは不十分
・人脈は組織を越える
・大学も共通のプラットフォームを使っちゃえば？
・ヤフーに替わるものがあるかどうか分からないけど、、、
・人脈の管理が現在はシステム的には不十分
・ヤフーアカデミックにおける取り組み
・Yahoo!メール Academic Edition、大学のフリーメールとして
・在校生、卒業生、教職員のコミュニケーション送出、卒業後も、インフラ無償
・人脈プラットフォーム連携
・メールだけではなく、ソーシャルなサービスも
・学内検索、学内で閉じたACLも
・人脈形成支援を行う上で必要な機能の提供
・サークルやゼミなどの、コミュニティ人脈形成支援機能の提供
・人がやらなきゃいけないことを極限まで減らす、情報を共有させる
・ヤフーが考えてること
・これまでの、ナンバーワン戦略の弊害
・マーケットインとプロダクトアウト
・マーケットイン、ターゲットを定め、求められている機能を調査し提供すること、顧客視点
・メリット：何をやればいいのかわかりやすい、効果が得られやすい、手堅い
・デメリット：想定の範囲内、イノベーションが生まれない、大変貌しない
・プロダクトアウト、論理や思想、技術などを軸に提案すること、事業者視点
・メリット：それまでに市場に存在しないような何かが生まれることがある
・デメリット：頭を使う、関係者が一丸となるのに時間がかかる、リスクが高い
・ニーズを満たすのではなく、ニーズに気がつかせてあげること
・人脈関連も、こちら側から提供して終わりじゃなくて、ユーザに考えさせる
・縦割りのヤフーが、横串を提供、社会に対する還元
Q.提供しているストック情報の提供との関係は？
A.web1.0的な情報だとかサービスだとかはもちろん使える、本物は本物。本物を育てるには、力やお金が掛かる。これまで同様必要。ただ、技術が変わっているので、それらをうまく組み合わせて
Q.人に見せたいものと、見せたくないもの、つながるものと、つながらないもの。匿名性と人格・人脈ネットワークに対する考えは？
A.本来人脈上では発言できないものが、匿名性によって活きる場合もある。匿名と、人格への紐づけを行わないということは別。匿名性は守るシーンもあるはず。人格の使い分けは実装すべきだと考える。
Q.局所的な平均化については？
A.確かに発生してしまうが、それらをコントロールできる仕組み（facebookでは、誰々の情報を抑制など、スライダーをつかって）を実装すべき、細かく調整できるように。ただ、日本人はカスタマイズが不得意（無関心？）。簡単にできるインタフェースを提供を検討したい
Q.パソコン＆ネットで人が色々退化してる、人脈形成の重要な能力を奪ってしまうかもしれない？
A.情報収集の時間を極端まで減らす、そして無にする時間を人に提供したい。下手したら、Yahooは1日3時間までとかで、使えなくなるとか（すばらしい）。Yahoo安眠（笑）。
投稿者 ymkx : 2008年12月 5日 11:57 |
15. DRBDと仮想化技術を利用した耐障害性と汎用性の高いサーバファームの構築 [セッション5: 分散システム]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)15. DRBDと仮想化技術を利用した耐障害性と汎用性の高いサーバファームの構築
○二川潤（法大）・下農淳司（京大）・雪田修一（法大）
・障害対策：ハードウェア部品の多重化
・各パーツの多重化は可能、が、ハイコストなものも多い
・アプリケーションレベルでの冗長構成を検討すべき、が、各アプリケーションで持っている訳じゃない
・仮想計算機によるサーバファーム
・潤沢な計算機資源の有効活用、運用する計算機全体での消費電力の低減、ハードウェア依存を無くす
・仮想計算機のディスクイメージ
・障害時にディスクサイズが大きいと時間がかかる、SAN構成→高い
・求められる環境
・耐障害性、ハードウェア故障時であっても短時間に復旧可能
・汎用性
・で、DRDB
・DRDB
・ディスクミラーリングソフトウェア
・フェイルオーバ型のクラスタ環境向け
・Linuxで動作
・TCP/IP経由で同期
・今後のバージョンは全てオープンソース
・ブロックデバイスとして動作
・計算機2台で、フル同期（初回、障害復旧時）、差分同期（通常運用時）
・似たような奴
・ファイルシステムより上位レイヤのもの
・lsyncd、バックグラウンドでrsync、バイナリファイルの差分転送は出来ない
・ファイルシステムより下位レイヤ
・開発中のものしかない
・構成
・Primary/Secondary、一台だけがデータの読み書き可能
・Primary/Primary、どちらの計算機でもデータを読み書きできる、が、GFSやOCSD2といったクラスタファイルシステムが必要、DRBDはファイルシステムに関して関与しない
・DRBDx2構成
・ありか
・ベンチマーク
・読み込みについては、自身のディスクから読むから大差なし
・が、書き込みは6割から7割遅くなる
・参照が多い分には無問題
・DRBDによる効果
・耐障害性
・汎用性
・仮想化技術
・実行環境全てが一つのディスクイメージ
・Linux以外のOSも可能
・筒底のハードウェアに依存しない
・DRBDと仮想化ソフトウェアを組み合わせる
・最小構成、計算機2台
・DRBDブロックデバイス上に仮想計算機を乗せる
・計算機資源の有効活用のため
・DRBDx2構成で
・確かに、これはいける
・もじら組サーバファーム
・確かによく落ちそう、、、
・この組み合わせは是非とも導入してみたい！
・とりあえず、Xenだな、、、DRBDも別で試してみたい
・今後の課題
・DRBDのPrimary/Primary
・管理の自動化、今は手動だもんね
Q.ディスクへの遅延書き込みをするようなソフト、メモリ上のデータは？
A.消えてしまう
Q.RDBとかは結構やっていると思うんだけど、、、
A.落ちたサーバ環境の復帰が最優先、RDBはRDBのレプリケーションを使う必要がある
Q.設定大変？ その辺のパッケージング化は可能？
A.出来るとは思う
Q.この環境下で実際に障害が起こったことは？ 実際の復旧ってどのくらい？
A.発生してない、想定練習では1～2分で復旧可能、BRDBのマスタ化とVMの起動
Q.BRDBのバージョンアップ等での工夫
A.カーネルモジュールなので、カーネルのバージョンアップ時には注意が必要、現状ではカーネルを自動的にバージョンアップはしない
Q.I/Oがあるものは不向きだけど、このシステムで最も守りたいものは？
A.とにかく早くWebサービスを復旧させること、SVNのリポジトリ運用とかではとにかく止めると、開発に影響が出るから
投稿者 ymkx : 2008年12月 5日 10:34 |
14. 投稿型動画視聴におけるユーザ間リアルタイムコミュニケーション支援システムの提案 [セッション5: 分散システム]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)
14. 投稿型動画視聴におけるユーザ間リアルタイムコミュニケーション支援システムの提案
○高野祐太郎・田島孝治・大島浩太・寺田松昭（農工大）
・投稿型動画サイト、youtube、ニコニコ動画
・これらの活性化には、ユーザー間交流が不可欠
・youtube、コメント
・ニコニコ動画、動画の各シーンに向けたコメント（字幕）
・既存の問題点
・リアルタイムコミュニケーション
・有益な動画の探索
・リアルタイムコミュニケーションを交えた共有動画同時市長システムの提案・思索
・コミュニティ形成による志向にあった動画の容易な発見
・同時視聴により会話が生まれるコメントなどの形でフィードバック
・製作意欲の増大、新たな動画の投稿
・循環による動画の質・量の向上
・提案システムイメージ
・直接動画サイトを見るのではなく、仮想的な視聴ルームに複数名のユーザーが集まり、そこから動画サイトを視聴する
・ふむふむ、なんか、サービス側の負荷軽減にもなるのかなぁ
・課題
・視聴者間の動画再生同期、参加者全員の一斉同期
・途中参加ユーザー、バッファリングが生じてしまった場合、ある参加者の個別同期
・バッファリング速度の差への対応が必要
・スケーラビリティの確保
・アクセス数増加に対応可能なネットワーク構成
・リアルタイムコミュニケーション方式の検討
・参加者全員の一斉同期
・バッファリング完了直後の再生開始同期
・同期サーバによる一括制御
・んー、この図ではストリーミングサーバの負荷は変わらないか、っていうか、同時視聴でかえって負荷向上？
・バッファリングを監視するのが同期サーバ
・ある参加者の個別同期
・視聴中ユーザの再生位置を同期サーバに通知して、その視聴位置に合わせて途中参加者の同期を行う、つまり途中から再生
・予測バッファリング時間の算出、これは難しい、、、現在はユーザの設定した回線速度から計算、これが適当＆ベストエフォートなのでちょっと難しいかも
・1回のバッファリングで完了は難しいけど、秒単位のオーダーなら2回くらいで何とかなりそう
・アクセス数増加を考慮したネットワーク構成
・動画配信から独立した同期制御網
・分散配信された動画同期再生可能
・同期制御部分の負荷軽減
・リアルタイムコミュニケーション方式
・テキスト
・ニコニコ形式、動画表示領域と、コメント表示領域をかぶせる
・ユーザー毎に発言コメントが流れる高さを固定
・音声
・Skypeを使用
・動作デモ
・途中入室同期すばらしい
・が、スゲー、ネットワーク的に離れた場合のデモが見たい
・評価
・視聴ルームの親と他メンバの動画再生同期ずれ調査
・目標値：動画再生同期ずれが200ms以下
・評価実験
・実際にインターネットを介して、FTTHとADSLで接続全て別々の回線
・Skypeを接続した場合とそうでない場合
・一斉
・ADSLの人たちは若干同期ずれ、しかし最大で116msのずれ
・Skype接続については影響はほぼ内
・個別同期
・これは大きくずれる、7秒とか
・ちょっとプログラムの問題か回線の問題か謎
・1人、大きく遅れるユーザが居るが、それはユーザのマシンスペックが低いため
・今後の課題
・安定した同期再生、様々な通信環境への対応、クライアント端末自体の性能差を考慮、巨大な同期ずれ発生への対応・抑制
・同期ずれの縮小
Q.テキストコメント、同時に100人とかだとどうなるの？
A.想定最大同時ユーザは、最大8人です
Q.クライアント間での同期は行わない？
A.行わない、サーバクライアント間
Q.マシンスペックの問題、回線の問題を排除するためにLANに持って行く実験はした？
A.やってない
確かにそれはアリだと思う
Q.コミュニケーションの結果の活用は？
A.将来的にサービスにする場合はロギングしたい
Q.同期コミュニケーションとかだと、e-learningとかで似たような研究があるかも
A.参考にしたい
投稿者 ymkx : 2008年12月 5日 10:16 |
13. ネットワークとアプリケーション協調を実現するプラットフォームの設計と実装 [セッション5: 分散システム]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)○岸田崇志・野田真・鳥居裕二・根本直樹・野坂正昭（ネットワンシステムズ）
・5分くらい遅れてはいる
・っていうか、これ、なんだろう？
・SMSC
・SSS Plathome
・アプリケーション側にネットワークを意識させずに、って話しみたい
・キャリア間連携
・キャリア2社のラボを接続したテストトライアル
・アプリケーションの連携とキャリア間連携
・アプリケーション連携
・各キャリアのリソースを活用しサービス提供に必要となるネットワーク品質を確保することが出来た、SOAPによるアプリケーション連携
・キャリア間連携
・APShere Technical specification R1.0を本にした参照実装
・国際テストベッドの構築、マルチベンダ・マルチキャリア・
・課題
・メッセージのパラメータの扱い方やその他のパラメーターの有無
・よりサービスの実態に即した、実用的なフレームワークの作成
投稿者 ymkx : 2008年12月 5日 09:37 |
2008年12月 4日
12. 年老いた恐竜は電子ナイフの夢を見るか？ - ε-ARK on Zaurs の開発 - [セッション4: セキュリティ(2)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)12. 年老いた恐竜は電子ナイフの夢を見るか？ - ε-ARK on Zaurs の開発 -
○大野浩之（金沢大）・猪俣敦夫（奈良先端大）
・年老いた恐竜＝Zaurus
・非常時にデータとか色々持って行きたい
・非常時？
・大規模災害とかパンデミックとか、国民保護法が想定する自体の勃発などのような、、、
・自助期、共助期、公助期
・非常時における自助期・共助期
・非常時における自助期・共助期とは、予期せぬ事態のために、デジタルデバイドされてしまっている基幹
・ε-ARK、非常時における自助期・共助期に使える多機能な情報通信機器！ 非常時対応電子アーミーナイフ
・ε-ARKコンセプト
・可搬性、汎用性、多様性、可用性、安全性
・何で作ってもよい
・ε-ARKデバイス
・Zaurus
・iPhone/iPodTouch
・Chumby
・android
・ε-ARKデバイスのある暮らし
・非常時に必要な多種多様の情報通信機能を主にソフトウェアで実現する
・それらを携帯電話やPDAに
・基本操作が簡単
・予期せぬ事態に遭遇しても、遅延無く使える
・消火器だって緊急時にはもたつく
・議論の前提となるε-ARKデバイスのある社会
・これからの日本
・これからの世界
・でも、今日はとりあえず日本、３Gネットワークが全国にあり、みんながワンセグ携帯を持ってる、コンビニ網が発達
・携帯電話が３G網とWiFi網の両方にアクセス出来るようになるかも、、、
・ワンセグは標準搭載、これすごい重要、大規模災害時にはめちゃくちゃ貴重
・サーバとして振る舞うことはないけど、ルータとして振る舞うことはありそう、それはもう始まってる
・携帯電話は緊急事態に使えないかもしれない、キャリア格差
・使えるリソースを被災者で分かち合いたい
・store&forward
・Webみるならキャッシュを駆使
・ローカルで共有できる情報は活用したい
・Zaurus SL-C3100
・Zarkの用途
・平常時、日常時、非常時
・日常業務支援
・非常時の道具として必要な機能
・情報発信、情報検索、情報交換
・電源確保ー
・電池で運用できるように
投稿者 ymkx : 2008年12月 4日 18:08 |
11. 学内ネットワークの安全性向上を目指したアクセス制御と脅威検知の導入 [セッション4: セキュリティ(2)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)11. 学内ネットワークの安全性向上を目指したアクセス制御と脅威検知の導入
宮下健輔（京都女子大）
・KWIINS、学内ネットワークシステム、200004-200703
・サーバはSolaris、FreeBSD
・KWIINS 2.0 200604-
・Mac OS X Server
・基幹、スター型、中心L3SWを二重化、配線を二重化
・周辺にL2SW
・運用体制
・情報政策委員会
・情報システム運営委員会
・職員（情報システムセンタ課長＋係長）
・常駐SE（サーバ2名、クライアント2名）
・教員（管理責任者、運用責任者）
・常駐SE＆運用責任者の3名でネットワーク・サーバの管理を、、、
・認証（KWIINS）
・DHCP利用申請書（紙）、MACアドレス登録（手動）
・ネットワーク利用申請書（紙）、固定IPアドレス、何も登録しない・接続確認無し
・不正利用は7年間で数件、未使用IPアドレスを勝手に振る、DHCPサーバを自前で起動（故意ではない、、、）
・学内・学外パケット調査、Worm、P2Pパケットなど検知せず
・感染防止
・L3SWにてaccess list記述、手動、ICMP、port 13[5789],445など
・W32.Blasterとかで効果有り
・が、サブネット内での感染を防げず、pandemic!!
・ネットワーク系の実習に不都合、ping、tracertコマンドだんめ、経路封鎖されてます！
・KWIINS 2.0
・DHCPでIPアドレス付与
・ユーザが指定のWebにアクセス
・L2SW(apresia2124)からradiusへ
・Macアドレス認証でOKな奴も、プリンタとか無線AP、紙で申請だけど、、、
・機器認証→ユーザ認証
・Macアドレス→ユーザ名＋パスワード
・2007年8月から部分的に開始、事前に文書配布、当日から質問、苦情の山、、、夏休み明けにも山、、、
・2007年12月に運用規則を改正
・2008年1月から全学で開始、平穏
・成果
・事前申請が不要になった
・即時性が向上
・一時的な接続が容易に
・アカウントのないユーザは利用不可、院生、研究員など、、、規則改正
投稿者 ymkx : 2008年12月 4日 17:29 |
10. 持ち出し禁止データを外部から安全に利用する一方法 [セッション4: セキュリティ(2)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)10. 持ち出し禁止データを外部から安全に利用する一方法
○三輪吉和（NPO学習開発研究所）・宮田仁（滋賀大）
・なぜこのシステムが欲しかった？
・みんな守ってくれない、、、実態に即していない
・データは自分で持っていたい
・よく知ってる人ほど、、、
・外出からファイルを修正・追加したい
・職場以外でパソコンを仕事のために使うこと、約8割が役に立つ
・私物PC、56%、セキュリティ対策が不十分
・シンクライアントではネット帯域が不十分
・パスワードロックや暗号化しても、、、
・パスワードロックは不完全、保守用パスワードの存在
・暗号化しても、自動復号であればやはり危険
・別媒体にコピーしたり、印刷したり、、、
・持ち出さずに外部で利用できれば
・LAN内のファイルサーバに対して、マルチサプリ間と機能を持つハブで、ユーザ認証後にサーバと接続、高い
・イントラネット経由でファイルサーバに対して、LAN拡張なので、、、
・勤務先のファイルサーバを直接利用できれば
・データの持ち出しが不要
・外出先で作成したデータをサーバに保存
・セキュリティ対策は
・サーバのデータは外部PCにコピーできない、コピー＆ペースト禁止、名前を変更しての保存できない
・印刷も禁止
・システム概要
・デモデモ
・設定作業が出来るだけ不要なこと
・利用するのは、貸与マシンとは限らない
・一般利用者が出先からでも利用できること
・クライアント側の概要
・キーを入れることで揮発領域をパソコン内蔵HDDに作る、ゲートウェイを通じてダウンロード・アップロード、ファイルは全て暗号化、
・USBキーを抜くと揮発領域を削除
・現在の課題
・ウィルス対策ソフトとの対象
・ファイル悪性中のファイル破壊対策、アクセス回線の障害とか、USBキーを抜いたとき
・アプリケーション連携をしているファイルを使用したいとき、アプリ側からファイルを呼び出せない
・まとめ
・勤務時間内に仕事を終えるのは無理
・データを持ち歩くのは危険
・USBキーにパスワードが貼られないことを祈るばかりじゃ、、、（笑）
Q.最初のHTTPSの通信の証明書は
A.USBキーに埋めたキーをサーバ側にも入れておく
投稿者 ymkx : 2008年12月 4日 17:24 |
9.はてなにおけるインターネットサービス群の継続的な開発と運用 [招待講演1]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)9.はてなにおけるインターネットサービス群の継続的な開発と運用
田中慎司（はてな）
・執行役員の人
・via NTT
・サーバインフラを支える技術
・はてなのはなし
・15のサービス
・はてなダイアリー、日記がキーワードでつながる
・はてなキーワード、キーワードでつながった日記を追いかけられる
・はてなブックマーク、ソーシャルブックマーク、集合値で人気・注目の話題が分かる、友人の見ているものが分かる、この前リニューアルした
・はてなスター、褒めることしかできないツール、相互に☆をつけあうとスターフレンドに
・コンセプト
・Fun & Creative
・ネットを通じて生活をゆたかにする
・ユーザーの集合知を極大化する
・会員80万人
・16億アクセス/month、6000万アクセス/day、1300万UU/month
・ハードウェア430台、仮想化により700台
・18ラック
・ピーク時300Mbps
・はてなでのサービス作り
・ユーザテスト・ヒアリング
・合宿
・社内発表・勉強会
・システムの全体像と解説
・三層構造、リバースプロキシ、アプリケーションサーバ、DB
・LVSを挟む
・三層構造がサービス毎に
・サーバ台数の割合、Web:DB=4:6～6:4
・全体の6～7割がweb or db
・非同期システムが増量中
・新ブックマークのシステム構成
・大変、、、40台から50台
・インターネットサービスの特徴
・スピードが大事
・永遠に完成はしない
・トラフィックの変動が急激
・小さい規模の頃は、ヤフーアタックとかですげーアクセスが急増、、、わかるわかる
・大規模サービスの運用
・スケーラビリティ、冗長性、省力運用、開発人数・開発方法、データ量
・スケーラビリティ
・多くのサービスはサーバ一台で動く、8GB/4コア
・が、大規模サービスはサーバ一台では動かない
・CPU負荷はスケールさせやすい
・I/O負荷はスケールが難しい
・用途毎のスケーラビリティ
・Webサーバはスケールさせやすい
・データソース（DB,Fileserver）は難しい、マスタのデータをどうスケールさせるか、パーティショニングなど
・パーティショニングをしすぎると、コストが高まる、検索などで困難なシーンも
・負荷の把握自社製、監視Nagiosを利用、OSの動作原理キャッシュメカニズムなどの監視
・スケーラビリティとソフトウエア開発
・大人数が利用することを前提に開発する必要
・少しのエンバグでサービスダウン、局所的な問題が全体に影響
・どのように解決？
・スケーラブルなアプリケーション設計・システム設計、OSSの積極利用
・推測しない、計測する
・プログラム言語の差異は全く支配的ではない
・ボトルネックは設計ミス、アルゴリズム選択ミス、I/O分散困難
・冗長性
・24時間365日100%の稼働率要求
・SPOF(Single Point of Failure)の除去
・Webサーバは冗長化しやすい
・データソースは冗長化が難しい
・基幹部分のネットワークは冗長化が難しい
・フェイルオーバー／フェイルバック
・冗長性とソフトウェア開発
・冗長構成で動作することを前提に開発する必要性
・解決策
・スケーラビリティとほぼ同様
・障害が発生したときの影響範囲の局所化
・故障することを前提に運用する、故障しやすい箇所の把握
・省力運用
・サーバが一台と複数台では運用コストが全く異なる
・350台のサーバ管理
・自作サーバ
・ケーブリングが大変になったり
・自作サーバ：金森、、、メーカー製の半額くらい
・ゴミが大量、、、
・運用が複雑になる箇所
・一台と450台で比較
・libcのセキュリティホール、アプリケーションのアップデート、サーバの設置場所、配線、、、
・多くの作業を自動化
・RPMやCapistrano
・OSインストールの自動化
・情報を整理する
・サーバ管理ツール
・IRC？
・データ量
・大規模サービスはデータ量が大きい
・データベースのレコード数、数百万から数億
・アクセスログ、1日で10GB
・大規模データ量に対する計算
・RDBMSの特性を正確に把握する
・アルゴリズムとデータ構造を工夫する、計算量を意識、分散アルゴリズム、統計処理 全体を対象としない
・分散処理系を活用する、分散ファイルシステム（HDFS, Mogile FS）、MapReduce
・サービス連携と継続的な開発のために
・柔軟なサービス開発、サービス間の疎結合
・高い効率・低コスト
・安定性
・サービス間の疎結合
・Pros、各サービス開発チームが個別に意志決定できる、開発速度の大幅な向上
・Cons、必要な情報が取得しにくくなる、開発コストの上昇、処理性能が劣化
・API化・利用の推進、生のデータベースを触らない
・プログラミング言語の統一
・作業の標準化
・API化・利用の推進
・API、Atom Publishing Protocol
・Feed、RSS?Atom
・汎用的なIFでアクセス
・ユーザへそのまま提供することも出来る
・プログラミング言語の標準化
・Python、Ruby、PHP、Perl、おなじレイヤーは一つに絞る、主にサーバサイドのウェブアプリケーション部分
・C/C++、メモリ効率、Apacheモジュールなど
・JavaScript、ActionScript、ユーザインタフェース
・プログラミングスタイルと設計
・オブジェクト指向
・他のエンジニアも触れるコードに
・保守性を考慮した設計
・アーキテクチャパターン、デザインパターン、イディオム
・MVC
・Model
・RDBを抽象化したライブラリ、ORマッパ
・ドメインロジックの再利用、DB詳細の抽象化
・Controller
・Webアプリケーションフレームワーク
・定型処理の抽象化
・View
・HTMLテンプレート
・デザイナとの絡み
・仕様を出来るだけコンパクトに保つ
・KISS、Keep It Simple, Stupid
・冗長な仕様は保守性を悪化させる
・アジャイル
・仕様書は書かない、スピード重視、コードをみれば分かる
・ミーティング重視
・テスト重要、テストが仕様である
・効率的な開発環境
・分散バージョン管理システム、git
・コードレビュー
・BTS、bug tracking system
・仮想化
・Xen
・仮想化によって得られるもの
・物理的なリソース制約からの解放、リソースの動的な変更、VMのマイグレーション・複製
・VM環境の統一か・標準化、自動設定ツール puppet、VMの自動的なインストールを可能に
・冗長化によるリソースの利用効率の低下を最小限に
・これはホントにうちも始めないと、、、
・んー、出来ることを出来る範囲で確実に進めているね
Q.Hadoopクラスターを新たに使い始めた差異の苦労した点
A.新たに使い始めた、全文検索のクローラーとして
Q.人数が増えてきて情報共有にかかるコストをどう抑えている？
A.アプリケーションの疎結合が基本、サービス開発チーム毎で決定出来る部分を増やす
Q.サーバ管理のIRCって？
A.監視システムのメッセージをメールと共にIRCにも流す、みんなでチェックしながら出来るので便利、情報共有ツールとして、コミットログなんかも流している、誰が何をやっているかとかもみんなで共有できる
Q.プログラミング言語の統一はどのように？
A.統一は、、、トップダウン、というかPerlが一番ノウハウがあるので
Q.JAVAはつかわない？ スクリプトって遅くない？
A.JAVAに強い人間がいない、、、スクリプトだからって遅い訳じゃない
Q.コードレビューでのセキュリティチェックで気にかけていることは？
A.diffをみてもらう、セキュリティはチェックリストがある訳じゃない、それぞれが判断
Q.性能orシンプル、VMを使ってサーバ台数が増えているけど、運用コストの増大は大丈夫？
A.そもそも、やらなきゃいけない冗長化を進めていたから増えている
投稿者 ymkx : 2008年12月 4日 16:29 |
8.Entropy Study on A and PTR Resource Records-Based DNS Query Traffic [セッション3: セキュリティ(1)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)8.Entropy Study on A and PTR Resource Records-Based DNS Query Traffic
デニスアルトゥロルデニャロマニャ・久保田慎一郎・杉谷賢一・○武藏泰雄（熊本大）
・ふはー、英語です、聞くので精一杯かも
・と思ったら、発表は日本人の先生だった
・DNSを攻撃検知のセンサーとして使う
・DNS reverse name resolution query request
・DNS Resolverをログエージェントとして使うと便利
・OP25B、最近は回避するSpam Botも居る
・Bindにログのオプションをつけて、クエリーを取る
・DNS Query Packets Traffic and Motivation
・結局、資料は英語だったので、聞くので精一杯、、、
投稿者 ymkx : 2008年12月 4日 15:15 |
7.サブネットワークにおける不使用IPアドレスを用いたインターネット観測手法とその評価 [セッション3: セキュリティ(1)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)7.サブネットワークにおける不使用IPアドレスを用いたインターネット観測手法とその評価
○桝田秀夫・竹内徹哉（京都工繊大）
・インターネット定点観測システム、攻撃のトレンドを観測するプロジェクト
・警視庁、SANS、JPCERT/CC、WCLSCAN
・インターネット上に観測ボックスを設置
・攻撃パケットのログを収集
・ログからトレンドを分析
・警報
・観測ボックスをなるべく多数設置したい
・観測ボックスに専用のIPアドレスが必要
・観測ボックスは攻撃に対してサイレントである必要がある
・IPv4アドレスは高価、枯渇も予測
・サブネット分割に着目
・サブネットに分割されてると、ネットワークアドレスやブロードキャストアドレスはホストであったとしてもおかしくない（見分けが付かない）
・よって、サブネットに分割された際のそれらのアドレスを観測アドレスとして使用する
・ルーターと観測ボックスを同居させる
・観測アドレス宛のパケットは中に流さない
・記録に電子署名を施して、ログ収集サーバに送付する
・基本的に応答を返さない（サイレント）
・ルーターに組み込む際は、パケットの分別処理が必要
・収集処理のオーバーヘッドがある
・iptablesで-j LOG,- REJECT
・評価
・転送速度への影響を観測
・結果
・模擬攻撃、dd if=/dev/urandom | socat -udp:192.168.0.32.10
・観測有り無し、全く転送速度の低下はない
・今後の課題
・ブロードバンドルータなどへの適用＞？？？ん？ あ、もうちょっとスペックの低い奴、実験はLinuxのPCサーバだからね
Q.ダークアドレスと不使用IPアドレスの関係は？
A.内容的にはちがうっぽい
Q.もっと、上流でやってみては
A.なかなかキャリアの理解が得られにくい、それよりは下流に手軽にたくさん置いて観測したい。どちらの法が効率がいいかは、今後の検討
Q.ミラーと実際のホストの設置で、取れる情報が違うか？
A.基本的に同じ
C.内部のボット検知には有利かもしれない
Q.ルーターのアドレスを使えば？
A.ルーターは外部から監視される可能性がある
投稿者 ymkx : 2008年12月 4日 14:48 |
6.TCPコネクション要求回数の計数による攻撃者の検知 [セッション3: セキュリティ(1)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)6.TCPコネクション要求回数の計数による攻撃者の検知
○衣笠雄気・大塚賢治・兒玉清幸・吉田和幸（大分大）
・不正侵入
・パケットフィルタリング
・管理者の負担増
・scan攻撃を抑制
・ICMP、TCP、UDP、この研究ではTCPで短期的な攻撃、SYNフラグのみが1のパケット
・存在ホストの探索
・大量の接続要求数
・スイッチでパケットを収集
・攻撃者検知システム
・単位時間あたりのTCPコネクション接続要求回数により判断
・IPアドレスと、IPアドレスからの接続要求回数
・接続要求回数は一定時間毎に更新
・ホワイトリスト、事前に静的に作成（クローラーなど）
・tcpdumpのパケットロスの問題
・httpは判断が難しい
・1分間に110以上の接続は攻撃者、、、
・長期的にスキャンを行う攻撃者は少ない
・関連研究、フレッツ・セーフティ、psad
・psad, iptables連携、管理者へのメール送信など
・ただ、大規模には対応が難しい
・帯域幅を小さく絞ったスロースキャンには未対応
・課題
・自動攻撃遮断システムの構築
・誤検知の低減が必須
・ログの解析
・対象とするscan攻撃の種類を増やす
Q.ホワイトリストを作らないと、何で誤認識するのか？
A.
Q.tcpdumpをデフォルトで使用？ セッティング次第でパフォーマンスが出るはずだけど
A.特に考えていなかった
Q.snortで十分なのでは？ このシステムの利点は
A.snortでも出来るけど、snortの設定が大変、簡単に設置できる
Q.内部から外に向けての攻撃を守ることは出来るか？
A.スイッチの設定次第で可能
投稿者 ymkx : 2008年12月 4日 14:10 |
5.休眠アカウント調査のためのWebを利用した情報サービス利用者確認システムの構築と運用 [セッション2: システム管理(2)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)5.休眠アカウント調査のためのWebを利用した情報サービス利用者確認システムの構築と運用
○櫻田武嗣・石橋みゆき・萩原洋一（農工大）
・教職員、学生、その他（企業などの研究者、短期留学生、単位互換性、聴講生）、約7000人、利用者情報の一元管理は難しかった
・アカウント管理、1996年12月、帳簿をMS Accessでデータベース化
・休眠アカウントの発生、大学構成員のデータが完全には一元管理できていない
・ソフトウェアライセンス・IPアドレスの無駄、不正利用
・これらの問題を解決
・2005年からデータベースの再構築
・Webベースのインタフェース、データの一元管理、利用申請の電子化、利用調査の電子化、システム登録の自動化
・情報系センターでの管理
・各種情報システムの管理
・大学機関ネットワークの管理
・一つのアカウントは1人の利用者が使うのが原則
・が、1人に対して複数のアカウント
・複数人に対して一つのアカウント
・とかが発生したり
・統一認証の導入だけでは難しい
・責任者の明確化、アカウント申請者が責任者
・統一認証システムはLDAP
・統一認証を用いないシステム、基幹データベースとか、これはしょうがない
・基幹データベースとの連携
・利用申請もオンライン上で常に受け付け
・申請の実システムへの反映も自動化
・利用受付に関して、本人からの申請かどうかを確認
・申請→登録DBからメールアドレスを抽出→メール内のURLクリックでWeb認証→登録チェック→登録
・申請中はロックがかかる、一度に色々させない
・パスワード忘れました、これが一番問い合わせが多い
・パスワード再発行機を構築
・MySQL、Apache2、PHP4(Zend,pear)
・8,153人、アカウント数27,338
・本題
・利用確認調査の実施
・チェックしただけで継続するように
・廃止の場合はWeb申請
・未回答者にメールで再度通知
・2008年は最終日にさらに通知、95%まで回答率を改善
・電子化で回答率が向上
・電子化してもしなくても、一定数は回答をしない
・毎年ほぼ一定数は回答しない(2.6%)
・毎年必ず回答しない人数も一定数（1.3%）
・今後は回答しない人の特徴をさらに分析し、対策を
Q.自前開発は、作った人間が抜けちゃったら、、、ベンダーは引き継いでくれるけど
A.既に作った学生は卒業、仕様をきっちりと作ってあるので大丈夫、DBもかなりきっちり。ソースは可読性の高いものにした、現在も他の人間が継続で改良中
Q.メール送信をトリガーにしてる、メールは必ず読むものですか？
A.メールを読まなかったら停止する、もはや半ば脅迫的に（すげー）
Q.全く回答しない人たちは？
A.毎年申請し直しです、本人が来ないような偉い先生、、、秘書がやってる、もー、困ったもんだ
Q.事務方との連携
A.自動的には出来ていない
投稿者 ymkx : 2008年12月 4日 11:54 |
4.「ISMS」と「グリーンIT」実現に貢献するSaaS‐アウトソーシング、シンクライアント戦略の推進 [セッション2: システム管理(2)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)4.「ISMS」と「グリーンIT」実現に貢献するSaaS‐アウトソーシング、シンクライアント戦略の推進
○井上春樹・八卷直一・長谷川孝博・高橋秀年・高田重利・望月邦昭（静岡大）・海野孝一・内田修司・田村孝広・相田剛・兼本正之（ビック東海）
・静岡大学実データ版
・省エネ対策
・現時点での消費電力低減予想
・現状：2,945,856kWh
・改善実施予想1：685,200kWh
・改善実施予想2：303,600kWh
・90%の削減！
・パソコン・サーバを、シンクライアント・パソコンに
・省庁自治体は99%削減できるとか、、、
・情報量の増大、IT危機の増大、電気喰いまくり、情報リスクも増大、やばい
・消費電力を毎年1/2以下に、リスクも同様
・従来のパラダイムじゃダメ
・地道に現実を定量的に測定、積極的に新パラダイムを考える
・IT資産の精密な調査
・消費電力実測
・環境負荷推定
・第1段階：アウトソーシング（他の大学の奴使え）、低電力IT機器開発
・第2段階：クラウドコンピューティングへの全面移行
・戦略推進後効果測定
・パソコン7000台、研究・開発用サーバ>300台、常時稼働Webサーバ555台！！！ いくら何でも多すぎる
・まずは測定、ワットチェッカーを使え、議論してる場合じゃない
・で、環境負荷測定
・第1段階：焼津に活断層がないのでそこに、プライベート・クラウド・コンピューティング・センター創設、サーバは全てクラウドへ、パソコンは出来る限りシンクライアントに、全端末のユニバーサル化
・S社のシンクライアントつかえねー
・自ら開発、Win2003っぽいかんじ、超低電力、\50000/台。本体はS社の奴
・150wがシンクライアントで16wに
・CG系はダメだけど、それ以外は全然おつけ
・第2段階：パブリッククラウド、GoogleCloud、Amazon EC2とか
・HaaS、PaaS、SaaS
・サーバは自前で持つな、クラウド使え、がんばるとエネルギーも情報リスクも90%以上減る
Q.シンクライアントの話し
A.S社のあれでWin2003を走らせる
Q.サーバコストは？
A.十分ペイできる
Q.ネットワーク負荷は？
A.ストリーミング以外では全く負荷が掛からない
Q.数字は測定に基づいているのか？ それとも申告に基づいているのか？
A.ハードは全て同定、グローバルアドレス、ポートから推定、もちろん調整はしてるけど
Q.グリーンITについて、資源についての視点は？
A.あくまで参考値として電力のみ挙げてる
投稿者 ymkx : 2008年12月 4日 11:45 |
3.目的環境に適合した最小パッケージ構成の自動構成システム [セッション2: システム管理(2)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)セッション2: システム管理(2)
3.目的環境に適合した最小パッケージ構成の自動構成システム
○八木貴之・桝田秀夫(京都工繊大)
・ネットワーク接続する組み込み機器の普及、セキュリティへの配慮、リソースの限定されたシステム
・Linuxの組み込み用途への適用、ネットワーク親和性、オープンソース
・最小化されたLinuxの必要性
・Linuxディストリビューションの特徴
・パッケージ管理システム
・インストーラの提供する最小構成、拡張性を考慮、数百MB
・小型装置で動くルータ
・独自ディストリビューションの開発、システムは最小化できるけど、セキュリティ・バグ対応、コスト高い
・既存ディストリビューションのカスタマイズ、セキュリティ・バグの対応はOK、でもバージョンアップのためにカスタマイズ、Linuxに耐する深い知識が必要
・目的環境に適合した最小パッケージ構成の自動構成システムの実現
・システム実現要求
・パッケージ単位の管理を崩さず
・対象ユーザは、Linuxに対する知識はない
・最小構成でインストール
・使用したファイルを一つでも含むもの
・依存ファイル
・それ以外を不要
・使用したファイルの探索
・a.目的用途に用いるプログラムの静的解析
・b.実際にどうさせアクセスしたファイルを記録
・b.を採用、ただし全てのファイルを網羅できるとは限らない、当然
・アクセスしたファイルの記録収集
・a.ファイルアクセスのシステムコールを監視、高コスト
・b.ファイルのアクセスタイムの記録、実際のシステム稼働に影響を与えない、読み込みモードでは記録が残らない、ntpdate
・b.を採用
・削除手順
・不要パッケージ群に対して依存関係を確認、削除の効率化
・依存関係の少ないものから削除
・相互依存のあるパッケージ、これは別のプログラムで
・実行で、ディスク使用量は半分程度に、パッケージも半分近くまで
・選択的パッケージ
・debconf-i18nとdebconf-english
・debconf-englishを選択することで936kByte減る
・依存関係を含むパッケージ群のインストールサイズ合計の比較、小さい方を選択
・但し、他の選択的パッケージの依存関係があるので、そこまでチェックする
・今後の課題
・パッケージ選択アルゴリズムのツールへの反映
・他のディストリビューションへの対応
Q.ディストリビューションが提示されている依存関係は全て正しかったですか？
A.未確認
Q.実際には要らない依存パッケージは？
A.今回は受け入れてしまっている、正常に動くとは思うけど、構成ポリシーを守るため
Q.180MBとか組み込みとしてはでかいけど、理想は？
A.256とかの区切りがよい、次は128を目指したい
投稿者 ymkx : 2008年12月 4日 11:09 |
2. PC演習室環境と共生するPCクラスタの構成法とその評価 [セッション1: システム管理(1)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)2. PC演習室環境と共生するPCクラスタの構成法とその評価
○大柚智・桝田秀夫（京都工繊大）
・演習室の使ってないマシンを、クラスタ化してしまえ
・演習目的の利用を妨げじゃいけない
・1日に何回も切り替えが発生、切り替えが短時間で出来る手法の確立
・セキュリティやメンテナンス上の問題がないこと
・クラスタプロセスを演習利用者から隠蔽
・演習利用者のプライバシーも保護、OSのインスタンスを個別に用意
・ノードの運用形態
・既存の方式：再起動、OSの切り替えの度に再起動は時間が掛かる
・提案方法：両方のOSを平行して稼働、OSの切り替え時間が減少、平行稼働の手段は仮想計算機ソフトウェア、オーバーヘッドで処理能力が低下、しかし1日辺りの処理能力が向上する
・仮想計算機ソフトウェアの決定
・UNIX環境、リソースの利用効率、HostOSからの操作のしやすさ、
・カーネルのアプリケーション化を選択
・実験環境の都合上、UML(User Mode Linux)を選択
・クラスタノードの設計
・演習用OSの上に制御モジュール、クラスタ用OSをのっける
・クラスタミドルウェア：SCore 6.0.2
・Linux、並列プログラミング環境、チェックポイント機能、ノード故障検知機能
・制御モジュールの動作、演習用OSへのユーザログインログアウトで、クラスタOSの起動、休止を制御
・評価
・仮想化によるオーバーヘッド
・N-Queen問題の計測時間
・ノード台数1-4でN=15に置ける計算時間を測定、総当たり法
・Native（仮想化無しクラスタ）とUML（仮想化有りクラスタ）の比較
・仮想化によるオーバーヘッドは15%
・1日辺りの処理能力で比較
・既存：21時から9時までの12時間稼働
・平行稼働：上記に加えて残り時間も使用、全て仮想化で
・損益分岐点82%、円周率利用率が82%未満なら1日辺りの処理能力向上
・ノード機能停止時の計算時間
・理想の相対性能に対して、50%低い、、、
・途中でログインが発生したときに、そいつのタスクを他の一台に割り当てちゃってる、、、そりゃだめだ、残りのノードにタスクをうまく分割させないと、途中で分割するのは困難、最初からバラバラにばらしておく、ここが今後の課題
・あと、復帰ノードに対するジョブの割り付けも問題
Q.演習OSに任せちゃえば？
A.セキュリティ上の問題で、クラスタプロセスと演習OSの分離しないと
Q.それはクラスタのOSがあほなんちゃうん（笑）？
Q.クラスタユーザへのメリットは？ 自分のジョブの終了時間が見えない
A.処理が短くなるメリットを最大限アピール
Q.SCore選定理由
A.将来的にはMPI環境に対応させたい、広島大学がSCoreを使っているとのことで（質問者SCore）
Q.SCore結構トラブってるんだけど、、、
A. ....
Q.OSのマイグレーション
A.現在設計中
Q.15%のオーバーヘッドって悪くない？ 他との比較
A.他のものでも、10%前後(VMWare)、今回は操作のしやすさとのトレードオフ
Q.演習室の利用率82%の分岐点は実際どのくらい？
A.利用者が60%前後なので満たしている
Q.何台くらいで使うと、よさげ？ もう、最近だったら買った方が安いとか
A.イメージしてるのは50-60台、演習室一室
Q.LinuxじゃなくってWindowsクライアントで動かす
A.CoLinuxを走らせるというのもアリ、性能もほぼ同じ
投稿者 ymkx : 2008年12月 4日 10:37 |
1.京都大学教育用コンピュータシステムの利用者管理 [セッション1: システム管理(1)]
[ReTweet This!] カテゴリ：第1回 インターネットと運用技術シンポジウム(IOTS2008)1.京都大学教育用コンピュータシステムの利用者管理
○池田心・森幹彦・上原哲太郎・喜多一・石橋由子・石井良和・竹尾賢一・小澤義明（京大）
・ちーこーくー、途中から
・講習会の参加コストが高い
・医療系スタッフ、社会人大学院生とか、参加が難しい人たち
・web講習会
・クイズ１０問、正解率一定以上で申請ＯＫとすることで、真剣に取り組ませる
・登録手続きのコストが高い
・一時アカウントシステム
・公開講座など短期利用者に通常手続きは重荷
・事前登録自動処理、重複チェックなど運用を考慮
・年間５０回程度の利用
・あ、これ、俺も使ったわ
・2段階変更webツール
・IDと同じくメールアドレスも長期継続利用
・適当なメールアドレスをつけて後で困る（就職活動）
・所属部局や名字が変更
・迷惑メール、ストーカー被害、、、こわい
・これらに対応すべく、利用者が任意のタイミングで「新アドレス登録」「旧アドレス無効化」できるシステムを構築
・年間50回程度利用
・課題の発見と教員の役割
・課題の発見法は様々、クレームを受ける、自分たちが利用して発見、ログを分析
・クレームは受け身、でも声を上げる人は僅か
・ログ分析、サービス毎の利用率、教員はメールと電子ジャーナルがほとんど、休眠アカウント
・運用系教員は利用者でも、技術職員でも事務職員でもないけど、それら全ての視点が必要
・自分の立場以外を想像するのは困難、それぞれの橋渡し役に
・自分たちが利用する、利用者の視点に立つために
・困ってることは色々あるけど、、、
Q.ストーカー的な奴は、アドレスを消すんじゃなくて吸収させた方が、で、その手の話しは技術的な視点だけじゃなくて、いろいろな人たちが連携すべきでは
A.現時点でそこまでしっかり連携はしていない
Q.ソフトウェアのライセンスの問題、ゲストアカウントとか、細かなアカウントの制御
A.いろいろ、教室単位など、あとベンダーと直接交渉
Q.利用環境の違いのチェックは？
A.全部は出来ないけど、出来る範囲で
Q.利用者講習はなぜ全員webにしないの？
A.学生と、意識が高い社会人との差。講習会で一斉にアカウントを発行するより、web講習の方がちょっとコストが高い。e-ラーニングの運用コストが高い、学生はとにかく意識が低い、、、講習会をやっても利用登録しない、、、学生相手はお願いじゃなくって強制的に
投稿者 ymkx : 2008年12月 4日 09:59 |
