ICTトラブルシューティング
コンテストのご紹介
@kyontan, @h-otter
自己紹介
- @kyontan
- 煙火打揚従事者
- (公開用に削除)
- Twitter: @sukukyon
- @h-otter
- (公開用に削除)
あらすじ
- 運営委員について
- トラコンの歴史
- 雑多な数字
- 人サイドの話
- トラコンを支える技術
- そして伝説へ…
- 燃えるガントチャート
- これが最後のスライドです
ICTトラブルシューティング
コンテストとは
- 通称 ICTSC
- ICT Trouble Shooting Contest
- 学生が学生に対してインフラ技術のトラブルシューティングをさせる大会
- 年2回 (春: 3月, 夏: 8月) 開催
- 次回は第9回, さくらインターネット株式会社 大阪本社で開催予定
もう少し詳しく
- 学生が運営し (※実行委員は大人の皆様です)
- 学生が参加し (※高校生, 大学生, 大学院生(修士), 専門学校生)
- 学生によって作られた会場ネットワークと問題を (※問題は何らかのトラブル)
- 学生が解いて
- 学生が採点する
開催までの流れ (1/2)
- 5ヶ月前: 運営委員結成, キックオフミーティング (合宿)
- 月1回程度でオフラインミーティング
- 適度な頻度で Skype ミーティング
- 回により頻度は異なる (後述)
開催までの流れ (2/2)
- (だいたいここから
) - 2週間前から: HotStage Phase 1@近場のCisco
- 全員が集まってもくもく作業
- 1週間前 HotStage Phase2@本番会場
- 配線, 機器設置, リハーサル, …
- 本番 (2日間)
- 撤収
運営委員について
- 大会を運営する学生 (16-22)人ぐらいの集まり
- 本番の5ヶ月ほど前に結成
- 本番で出題する問題を作成するのが主な仕事
- その問題を出題する環境を作るために 様々な技術 を導入していく
- 問題を出題するためにそれが必要なのかは別問題
- 環境構築が好きな人間の集まり(?)
- その問題を出題する環境を作るために 様々な技術 を導入していく
経歴
- @kyontan
- 第5回 (2016春) から運営委員として参加
- 第6回: 副リーダー, 第7回: インフラリーダー
- コンテストサイト(後述)担当
- 第9回は非運営委員担当
- @h-otter
- 第6回 (2016夏) から運営委員として参加
- 第7回: 問題リーダー
- バックボーンネットワーク担当?
歴史
会場
会場
- 第1回: 大阪情報コンピュータ専門学校
- 第2回: 日本電子専門学校 (東京)
- 第3回: 帝塚山大学 東生駒キャンパス (奈良)
- 第4回: 工学院大学 (東京)
- 第5回: シスコシステムズ合同会社 東京本社
- 第6回: NTT西日本 研修センタ (大阪)
- 第7回: NTT東日本 中央研修センタ (東京)
- 第8回: 電気通信大学 (東京)
- 第9回: さくらインターネット株式会社 大阪本社
出題範囲
- ~ 第2回
- Cisco のネットワーク機器 (物理) のトラブル
- 第3回 ~
+ サーバ (VM) を使用したトラブル (Linux) - 第5回
+ FreeBSD を使用したトラブル - 第8回
+ Juniper 機材を使用したネットワークトラブル
(ネットワーク機器を使う問題: ネットワーク問題, サーバを使う問題: サーバ問題)
実際に出題された問題
回答例
雑多な数字 (1/2)
- 参加者: 15チーム, 70名程度 (3~5人/チーム)
- 運営委員: 20名程度 (15~22人)
- 実行委員: たくさん
雑多な数字 (2/2)
- 16 Physical Servers @ICTSC8
- Used 8 Physical Servers on Stage
- 300VM on 5 Physical Servers
- 350 VLANs
- More than 100 Network Router / Switch
- Not Nintendo
技術サイドの話
トラコンを支える技術 (1/4)
- ネットワーク (主に TCP/IP) 技術
- サーバ (主に Linux) 技術
- 仮想化基盤
- XVMほど
トラコンを支える技術 (2/4)
- プロビジョニング等の自動化技術
- 展開の高速化, 属人性を下げる
- 監視
- ユーザに気付かれる前に
隠滅したい
問題を解決したい - パトライトの HTTP API
- ユーザに気付かれる前に
トラコンを支える技術 (3/4)
コンテストサイト
- https://github.com/ictsc/ictsc-score-server
- 問題の質問, 解答提出, 採点の統一管理システム
- 中身はただの Webアプリ
(Ruby + Sinatra + Vue + …) - (第5回以前は Redmine の手動運用)
- 第6回で開発 (負荷爆発)
- 第7回で改善 (安定運用 + ルール変更)
- 第8回で若干改善 (+プッシュ通知)
- 中身はただの Webアプリ
トラコンを支える技術 (4/4)
(スコアサーバの画像ですが諸事情により削除)
仮想化基盤 (1/2)
- そもそもなぜ使うのか?
- 1つのサーバ問題で1つサーバーが必要とすると、 xチーム数(15チーム)分必要になる
- 10問出題されたら: 150台
- 物理のサーバはそんなに数がない
仮想化基盤 (2/2)
- 仮想化しよう！
- VM (バーチャルマシン)
- 1台のサーバに複数の仮想サーバを詰め込む
- 商用サービスでは、例えば さくらのクラウド / AWS EC2 / GCP などなど
- やっぱり手元にある方が 楽しい
- それを実現するソフトもあります
代表的な仮想化基盤技術
- VMWare vSphere / vCenter
- QEMU
- KVM
- Xen
これらに仮想ネットワークやストレージ機能などをもたせたものが IaaS (Infrastructure as a Service)
代表的な IaaS を実現する
OSS なソフトウェア群 (1/2)
- OpenStack
- Redhat, IBM, Intel などなどが関与している
- 日本だと Fujitsu や NTTコミュニケーションなどなど
- Python 製
- 世界シェアはトップ(なはず)
- 様々な問題を抱えている
代表的な IaaS を実現する
OSS なソフトウェア群 (2/2)
- Apache CloudStack
- Citrix などが関与している
- IDCF のクラウドはこれがバックエンド
- 世界シェアは2位?
- Java 製
- 様々な問題を抱えている
仮想化基盤の変遷
- 第3, 4回 VMWare ESXi vSphere
- 第5回: OpenStack Liberty
- 第6回: CloudStack
- 第7回: OpenStack Newton
- 第8回: OpenStack Ocata
- 第9回: ???
第6回 (1/2)
これが動かなくてすごい! 2016
- CloudStack
- 動かなくてすごい
- デフォルト設定ではネットワークルータがメモリ不足で死ぬ
- デフォルト設定では1テナントの上限は 50VM
- スケールさせる気持ちはどこへ
- 劇的に渋い API / 値の仕様が分からない
- シェルスクリプトで自動化して問題を強引に解決
第6回 (2/2)
- 突然 Linux カーネルモジュールを書き始める
- netfilter でブリッジをするパケットの書き換え
- レイテンシが少なくてすごーい (0.2ms)
- github.com/a-r-g-v/ictsc6-nat-module
- 知見: Linuxカーネルモジュールは一夜にしてならず
- 三日三晩でも終わらない
第7回
- OpenStack で 平和 にやろう
- 当たり前のことを当たり前にやる
- Packstack で構築
- Ansible の OpenStack モジュールでプロビジョニング
- ネットワークも前回の知見を活かし、OpenFlowを使っていい感じに展開
- トポロジ自体はシンプルなスター型
第8回
- 第7回の知見を活用
- 僕は詳しく把握してなくて @h-otter プロがだいたいどうにかした
- コンテストサイトにテストを書いてまともにする
- 権限昇格の脆弱性
root が奪取できる- 未公開の問題, 他人の解答が見られる
ここまでは客観的な話
ここからは主観的な話
@kyontan から見た…
運営 / 人的な話
第5回 (1/2)
- あまり覚えていない
- 平の運営委員としては、分からなかったことが多かった
- 用語 / 流れ / やるべきこと / スケジュール感
- 情報がうまく伝達されていない
第5回 (2/2)
- タスクの割り振りが偏っている
- スキルは偏っているので難しい…
- タスクは GitHub Issue で管理していた
- タスクの細分化などに知見がなく、また更新頻度も低かった
第6回 (1/2)
- キックオフ合宿を導入 @山喜旅館
- 最初に用語やら流れやらを突っ込んだり
- ??「人間DNSがいれば回る」
僕「やればええんやな???」 → やった- 「あの情報は?」「あのページに」
「この情報は」「このページに」
- 「あの情報は?」「あのページに」
- ありとあらゆる情報を Wiki にまとめるように
- 延々と Wiki を更新してまとめ続ける僕
- 数値データは
神ExcelGoogle Sheets で一括管理- LANケーブルの本数, 使用先, 計算リソース, …
第6回 (2/2)
- 僕がタスクを抱えて死んだ
- リーダーはマネジメントに集中すべき
- クリティカルパスを抱えて死ぬ人間の一例
- タスクを 把握 している人間が集中した
- 暇なメンバーの発生
- ギスギスする
- 難しい……
第7回 (1/2)
- インフラリーダーになった
- これで運営委員やめるぞ! と思っていた (結論としては失敗した)
- チームを分ける, タスクを分ける
- 知見の共有を推進
- Wiki の更新頻度を上げる
- みんなに書いてもらう
- とにかくなんかあったら「Wikiに書いて」
- 僕はインフラに詳しくなかった
第7回 (2/2)
- 小さいチーム
- 大きいチームは同期が難しい (日程決まらない問題)
- 頻繁に情報を同期するように
- 動いている人の割合を高める
- 動いているかの状態を把握
- クリティカルパスを出来る限り分離/分散
- ある程度バラバラに進めてあとからマージ
- マージのコストが高くても良い
(※HotStageの存在)
上手く行った(かな?)
(※コンテストサイトの存在)
@h-otter から見た…
第6回
- 右も左もわからずとりあえず頑張った
- なんか準備期間中何もしてなくて不安だったけど、やはり燃えた
- 2週間泊まり込みで作業し、
部屋がひどかった睡眠時間を覚えてない
問題ができてない
インフラも安定してない
そもそも15チーム分15問展開するけど、
だれがAnsibleとか書くの
書ける人 (少人数) が書くらしい
キレたので
- github.com/a-r-g-v/ictsc6-nat-module を開発
- 解答者は同じIP、運営は一意なIPで問題VMにアクセスできる
- つまりVMはコピペするだけで展開される
- 第6回以降スタンダードな手法になる
- 2週間しかない中でLinux kernel code reading & ロジックのデバッグ
- 開発に関係のない人には早くしろといわれ、ギスギスする我々
- L3スイッチのL2フォワーディングテーブルが汚染され、壊れるネットワーク
楽しむはずの打ち上げで一言
「早く帰って寝たい」
第7回
問題リーダになり目標を設定した
競技性を高めて
参加者に楽しんでもらう
第6回まで
- 毎回運営するだけで必死だけど、いったい何のためにやってるの?
- 参加者に楽しんでもらって、インフラの仕事やってほしいでしょ
第6回まで (問題について)
- 1日目、2日目の午前午後で出題する問題を計4ブロックに分けていた
- 問題の準備ができてなかったり…
- でもトラブルって3時間くらいかけたうち結局気づきが生まれたら一瞬ですよね
- ポイントの公平性について結構毎回ドキドキしてる
- 記述式なので採点基準が公平なのか
- そもそも問題の配点は正しいのか
第7回は
- 以下の点を明確に
- スタートの状態
- ゴールの状態
- 技術的なトラブルの根拠
- 仮想敵チームをいくつか設定して点数調整
- warmupを作成
- 全チーム6割程度と言うてもらえるように…
- シナリオ・ゲームルールを作り、適切に公開
- 安定感のあるインフラ
第7回の結果
- 競技性は確保できたらしい
- それなりに参加者に楽しんでもらったらしいのでうれしい
- インフラもかなり安定していた
- 得点設定は結局よくなかった
- 大人チームが8割、1位が6割程度、ほかは…みたいな
- ネットワークとサーバで得意分野が分かれるので仕方がないかもしれない
打ち上げにて
ウェーイ！！ 
第8回
目標が決まらなかったが、
機材がいっぱいあったので
スキにインフラを作った
第8回 BB説明
第8回 BB説明 (機材)
- Juniper
- EX4600 (Spine switch)
- SRX650 (Edge router)
- MX5 (VXLAN gateway)
- Cisco
- Catalyst 4948E (TOR)
- Catalyst 2960X (アグリゲーション)
- Aironet 2504 (WLC)
- Aironet 3702E (802.11ac対応!)
- NEC
- IX2105 (対外ルーター)
- お借りした機材で家が立つ
第8回 BB説明
詳細が気になる方は、今夜にでも…
第8回を終えて
- マネジメントは難しい
- スキルセットが違う
- ほとんど初対面
- 最優先は学業
給料もない
- 人の入れ替わりもある
- 適材適所のマネジメントが必要
- スコアサーバの引き継ぎに失敗したまま @kyontan は引退した
Wiki近況
/commons: 21ページ/ictsc5: 40ページ/ictsc6: 135ページ/ictsc7: 145ページ/ictsc8: 174ページ/knowledge: 20ページ
合計: 535ページ
/user はカウントしていません
(Wiki のページ一覧の様子ですが公開用に削除)
気づき
運営学生は燃えることを楽しんでいるドM
そして伝説へ…
そして伝説第9回へ…
(あと5分ぐらい残ってて欲しい)
夢
n0stack
全く新しい IaaS
全く新しいIaaS
とある場所のとある会話
「CloudStackは○○」
「わかる」
「OpenStackはでかい」
「わかる」
「作れば良くない?」
「わかる」
-> n0stack
クラウド基盤つらい2017
- 何であるのかもわからない程多いリッチな機能群
- IaaS基盤だけでもでかいのに、いろいろなプロダクトに対応すればでかくなるのは自明
- 他人の書いたコードのデバッグはしんどい
- 自動構成ツールは動かない
openstack-ansible
- 企業で使っている人たちは大抵魔改造しているので、全く別物
求められているもの
- 不要な機能やプロダクトへの対応を削除
- KVMが動けば基本的になんでもいい
- チーム数分VMやネットワークを展開できるような仕組み
- 面白いもの
- 開発者のモチベーション
- 我々は AWS, GCP, さくらのクラウド, …を
使うだけではなく、
それを構成する技術を理解する必要がある
*aaS を理解する
求められているもの
燃えるガントチャート
突然の登壇
おわりの始まり
我々が使っているのはコンテナ技術ではない
自作仮想化基盤「n0stack」の紹介
そこでデモをします!
これが最後のスライドです
http://bit.ly/csig17f
ICTトラブルシューティング コンテストのご紹介 @kyontan, @h-otter
{"metaMigratedAt":"2023-06-14T14:32:40.547Z","metaMigratedFrom":"YAML","title":"自己紹介","breaks":true,"slideOptions":"{\"transition\":\"slide\"}","contributors":"[]"}