## ICTトラブルシューティング<br>コンテストのご紹介 @kyontan, @h-otter --- # 自己紹介 - @kyontan - 煙火打揚従事者 - (公開用に削除) - Twitter: @sukukyon - @h-otter - (公開用に削除) --- # あらすじ 1. 運営委員について 1. トラコンの歴史 1. 雑多な数字 1. 人サイドの話 1. トラコンを支える技術 1. そして伝説へ... 1. 燃えるガントチャート 1. これが最後のスライドです --- ## ICTトラブルシューティング<br>コンテストとは - 通称 **ICTSC** - ICT Trouble Shooting Contest - 学生が学生に対してインフラ技術のトラブルシューティングをさせる大会 - 年2回 (春: 3月, 夏: 8月) 開催 - 次回は第9回, さくらインターネット株式会社 大阪本社で開催予定 --- ## もう少し詳しく - 学生が運営し (※実行委員は大人の皆様です) - 学生が参加し (※高校生, 大学生, 大学院生(修士), 専門学校生) - 学生によって作られた会場ネットワークと問題を (※問題は何らかのトラブル) - 学生が解いて - 学生が採点する --- ## 開催までの流れ (1/2) - 5ヶ月前: 運営委員結成, キックオフミーティング (合宿) - 月1回程度でオフラインミーティング - 適度な頻度で Skype ミーティング - 回により頻度は異なる (後述) --- ## 開催までの流れ (2/2) - (だいたいここから :fire:) - 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 機材を使用したネットワークトラブル <small>(ネットワーク機器を使う問題: ネットワーク問題, サーバを使う問題: サーバ問題)</small> --- # 実際に出題された問題 --- # 回答例 --- ## 雑多な数字 (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) - プロビジョニング等の自動化技術 - 展開の高速化, 属人性を下げる - 監視 - ユーザに気付かれる前に~~隠滅したい~~</br>問題を解決したい - パトライトの HTTP API - https://github.com/kyontan/patlite-api --- ### トラコンを支える技術 (3/4) #### コンテストサイト - https://github.com/ictsc/ictsc-score-server - 問題の質問, 解答提出, 採点の統一管理システム - 中身はただの Webアプリ<br>(Ruby + Sinatra + Vue + ...) - (第5回以前は Redmine の手動運用) - 第6回で開発 (負荷爆発) - 第7回で改善 (安定運用 + ルール変更) - 第8回で若干改善 (+プッシュ通知) --- ### トラコンを支える技術 (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 を実現する<br>OSS なソフトウェア群 (1/2) - OpenStack - Redhat, IBM, Intel などなどが関与している - 日本だと Fujitsu や NTTコミュニケーションなどなど - Python 製 - 世界シェアはトップ(なはず) - 様々な問題を抱えている --- ### 代表的な IaaS を実現する<br>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 が奪取できる~~ - 未公開の問題, 他人の解答が見られる :fearful: --- ## ここまでは客観的な話 --- ## ここからは主観的な話 --- ## @kyontan から見た... --- ## 運営 / 人的な話 --- ### 第5回 (1/2) - あまり覚えていない - 平の運営委員としては、分からなかったことが多かった - 用語 / 流れ / やるべきこと / スケジュール感 - 情報がうまく伝達されていない --- ### 第5回 (2/2) - タスクの割り振りが偏っている - スキルは偏っているので難しい... - タスクは GitHub Issue で管理していた - タスクの細分化などに知見がなく、また更新頻度も低かった --- ## 第6回 (1/2) - キックオフ合宿を導入 @山喜旅館 - 最初に用語やら流れやらを突っ込んだり - ??「人間DNSがいれば回る」<br>僕「やればええんやな????」 → やった - 「あの情報は?」「あのページに」<br>「この情報は」「このページに」 - ありとあらゆる情報を Wiki にまとめるように - 延々と Wiki を更新してまとめ続ける僕 - 数値データは ~~神Excel~~ Google Sheets で一括管理 - LANケーブルの本数, 使用先, 計算リソース, ... --- ## 第6回 (2/2) - 僕がタスクを抱えて死んだ - リーダーはマネジメントに集中すべき - クリティカルパスを抱えて死ぬ人間の一例 - タスクを **把握** している人間が集中した - 暇なメンバーの発生 - ギスギスする - :fire: - 難しい…… --- ## 第7回 (1/2) - インフラリーダーになった - これで運営委員やめるぞ! と思っていた (結論としては失敗した) - チームを分ける, タスクを分ける - 知見の共有を推進 - Wiki の更新頻度を上げる - みんなに書いてもらう - とにかくなんかあったら「Wikiに書いて」 - 僕はインフラに詳しくなかった --- ## 第7回 (2/2) - 小さいチーム - 大きいチームは同期が難しい (日程決まらない問題) - 頻繁に情報を同期するように - 動いている人の割合を高める - 動いているかの状態を把握 - クリティカルパスを出来る限り分離/分散 - ある程度バラバラに進めてあとからマージ - マージのコストが高くても良い (※HotStageの存在) --- ## 上手く行った(かな?) (※コンテストサイトの存在) --- ## @h-otter から見た... --- ### 第6回 - 右も左もわからずとりあえず頑張った - なんか準備期間中何もしてなくて不安だったけど、やはり燃えた - 2週間泊まり込みで作業し、 ~~部屋がひどかった~~ 睡眠時間を覚えてない --- #### 問題ができてない --- #### インフラも安定してない --- #### そもそも15チーム分15問展開するけど、</br>だれがAnsibleとか書くの --- #### 書ける人 (少人数) が書くらしい --- :fire: --- ### キレたので - github.com/a-r-g-v/ictsc6-nat-module を開発 - 解答者は同じIP、運営は一意なIPで問題VMにアクセスできる - つまりVMはコピペするだけで展開される - 第6回以降スタンダードな手法になる - 2週間しかない中でLinux kernel code reading & ロジックのデバッグ - 開発に関係のない人には早くしろといわれ、ギスギスする我々 - L3スイッチのL2フォワーディングテーブルが汚染され、壊れるネットワーク --- ### 楽しむはずの打ち上げで一言 「早く帰って寝たい」 --- ### 第7回 --- ### 問題リーダになり目標を設定した --- ### 競技性を高めて</br>参加者に楽しんでもらう --- ### 第6回まで - 毎回運営するだけで必死だけど、いったい何のためにやってるの? - 参加者に楽しんでもらって、インフラの仕事やってほしいでしょ --- ### 第6回まで (問題について) - 1日目、2日目の午前午後で出題する問題を計4ブロックに分けていた - 問題の準備ができてなかったり… - でもトラブルって3時間くらいかけたうち結局気づきが生まれたら一瞬ですよね - ポイントの公平性について結構毎回ドキドキしてる - 記述式なので採点基準が公平なのか - そもそも問題の配点は正しいのか --- ### 第7回は - 以下の点を明確に - スタートの状態 - ゴールの状態 - 技術的なトラブルの根拠 - 仮想敵チームをいくつか設定して点数調整 - warmupを作成 - 全チーム6割程度と言うてもらえるように… - シナリオ・ゲームルールを作り、適切に公開 - 安定感のあるインフラ --- ### 第7回の結果 - 競技性は確保できたらしい - それなりに参加者に楽しんでもらったらしいのでうれしい - インフラもかなり安定していた - 得点設定は結局よくなかった - 大人チームが8割、1位が6割程度、ほかは…みたいな - ネットワークとサーバで得意分野が分かれるので仕方がないかもしれない --- ### 打ち上げにて --- ## :tada: ウェーイ！！ :beers: :tada: --- ## 第8回 --- ### 目標が決まらなかったが、</br>機材がいっぱいあったので</br>スキにインフラを作った --- ## 第8回 BB説明 - 長いので別スライドをご参照ください<br>(おすすめです @kyontan) http://www.slideshare.net/h-otter/ictsc8-backbone (http://bit.ly/ictsc8bb) --- ## 第8回 BB説明 <img src="https://i.imgur.com/txIXY2v.png" width=800> --- ## 第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ページ <small>/user はカウントしていません</small> --- (Wiki のページ一覧の様子ですが公開用に削除) --- ## 気づき --- ### 運営学生は燃えることを楽しんでいるドM --- ## そして伝説へ... --- ## そして~~伝説~~第9回へ... --- (あと5分ぐらい残ってて欲しい) --- # 夢 --- # n0stack --- # 全く新しい IaaS --- # ~~全く~~新しいIaaS --- ## とある場所のとある会話 「CloudStackは○○」 「わかる」 「OpenStackはでかい」 「わかる」 「作れば良くない?」 「わかる」 -> n0stack --- ## クラウド基盤つらい2017 - 何であるのかもわからない程多いリッチな機能群 - IaaS基盤だけでもでかいのに、いろいろなプロダクトに対応すればでかくなるのは自明 - 他人の書いたコードのデバッグはしんどい - 自動構成ツールは動かない :boom: - ~~openstack-ansible~~ - 企業で使っている人たちは大抵魔改造しているので、全く別物 --- ## 求められているもの - 不要な機能やプロダクトへの対応を削除 - KVMが動けば基本的になんでもいい - チーム数分VMやネットワークを展開できるような仕組み - 面白いもの - 開発者のモチベーション - 我々は AWS, GCP, さくらのクラウド, ...を<br>使うだけではなく、<br>それを構成する技術を理解する必要がある --- ## *aaS を理解する --- ## 求められているもの https://github.com/n0stack/n0core --- ## 燃えるガントチャート ---  --- ## 突然の登壇  --- ## おわりの始まり ---  ---  <small>我々が使っているのはコンテナ技術ではない</small> --- # 自作仮想化基盤「n0stack」の紹介 --- # そこでデモをします! --- ## これが最後のスライドです # http://bit.ly/csig17f