Upgrade to Pro — share decks privately, control downloads, hide ads and more …

歴代の運営委員と上位入賞者が語る ICTSC攻略

KATSUYA
October 25, 2019

歴代の運営委員と上位入賞者が語る ICTSC攻略

KATSUYA

October 25, 2019
Tweet

More Decks by KATSUYA

Other Decks in Technology

Transcript

  1. 目次 • 自己紹介 • 大会概要 • 大会の変遷 • マネジメント視点から見た運営 •

    作問者側からの視点 • 先日行われた1次予選について • 参加者視点から見た攻略法 • 参加者攻略ネットワーク編
  2. 大会概要 規模感 • 使用機材:200台 • VM数:ICTSC2018 本戦 700, ICTSC2019 1次予選 1600

    • 関係者 ◦ 20人前後の学生運営委員会 ◦ 75~250人前後の学生参加者 ◦ 10~20人程度の実行委員会 ◦ 場所提供、機材提供、協賛の企業様方 • 構想半年、現地準備2週間、本番2日、撤収1日
  3. 大会概要  変遷 • 大会規模の拡大 ◦ 参加者の増加   → 対応事項の増加 ◦ 機材の増加    → 電源容量による開催地の制約 ◦ VMの増加    

    → 展開技術の洗練 ◦ ルールの変更   → 競技性・公平性の保持 ◦ 大会回数の減少  → 予選の開催 • トラコン予備校の開催
  4. 運営のマネジメント視点 何を管理するか? • 運営学生20人            モチベーションの高さは様々 • 参加者の対応             公平性を保持 • スケジュール             リスケは効かない • 機材                 高価なもののレンタルなので・・ •

    会場                 電源系統に注意 • バックボーン構築           検証に時間が必要 • 手元環境の構築            大量にあるので物理展開が大変 • 問題作成・検証・展開・解説      各自の進捗がバラバラ • 競技ルール・資料           資料にミスが起きがち • スコアサーバーの開発・運用      開発人員の確保 • DC作業・搬送             検証環境の構築・会場への搬送 • 会場提供・機材提供・協賛の企業折衝 コミュニケーション能力必須
  5. 運営のマネジメント視点 管理担当の決定 • 運営リーダー     運営学生20人 • 進行担当     全体スケジュール • 機材担当       機材 • 会場担当       会場

    • バックボーン担当   バックボーン構築 • 手元担当       手元環境の構築 • 問題担当       問題作成・検証・展開・解説 重いタスクを各担当に割り振り、必要な仕事などを各担当ごとに全てwikiにまとめて継 承出来るようにした 対外への折衝は統一ルール等や継承者を育てることにした           → タスクベースで役割を作るのは、当たり前なのか?
  6. 運営のマネジメント視点 前は • 運営リーダー     運営学生20人+難しいこと全部 • 副リーダー    ふわふわ • イベントサポート   機材・会場・雑用全部 • インフラリーダー   バックボーン・手元環境の構築

    • 問題リーダー     問題作成・検証・展開・解説 元々の運営は人材も限られていて規模も小さかったため管理職は少なくても何とか回っ ていた? 人材が限られた学生運営ではタスクベースでの役職作成は難しい タスクを任せられる人間に役職を作り、タスクを任せるマネジメントを行った       → 運営がホワイトであることと大会の質をあげることに貢献
  7. 問題を作るときの悩み • どこまで情報を出すか • 禁則事項が答えに直結しないか • ヒントを出し過ぎていないか • これ簡単すぎないかな? •

    大抵の場合は結果的に難しい場合がほとんど • そんなに全員が全員解けるわけではない • 難易度・配点調整が難しい • この難易度でこの配点 高くor 低く ないですか? • 想定外の解き方への対処
  8. 修正が発生したときが一番辛い • 既にアーカイブしたものからの修正が一番辛い • 修正したと思ったら別のトラブルが多発 • 再アーカイブ化したらトラブルが起きていない • ログインができなくなった •

    /var/log, historyを消し忘れている • 結局ベースイメージから作り直したほうが速い場合がある • 構築メモは残しておこう!(いつVMが消えるか分かりません)
  9. 採点について • 予選 • 全58チーム分 • 土曜日に実施、その日の夜から日曜にかけて採点、月~火曜に公表 • 本戦 •

    本戦に出場できるのは15チーム • 解答が提出され次第随時採点 • 競技終了後の表彰式までに確定しないといけない • 約1時間半
  10. 出題方式と採点基準 • 出題方式 • 前回の本選では問題開放方式というものを採用している • 前提の問題が解けたら次の問題が解けるという方式 • 得点について •

    基準点(正解とする基準)と満点(100%)が存在する • 問題ごとに採点基準は設けられており、 トラブルが解決していたら基準点は必ず与えている • 満点にならない理由は様々 • 解答の説明が正しくない • 一部設定が抜けている
  11. ICTSC2019 1次予選 概要 • 8/31(土) オンライン予選 • 競技時間 13:00 ~ 18:00 • 全57チーム

    • 1チームあたり 28VM, 合計1596VM • ちなみに去年は49チーム, 1764VM
  12. 問題例: 問題文 問題文
 Kubernetes クラスタ環境を移行後、Kubernetes上のWordPressにアクセスできなくなりました。 
 原因をつきとめ、修正してください。 
 
 情報


    Kubernetesクラスタの移行手順書は存在しません。アドレスレンジに以下の変更があったことのみ分かっていま す。
 * Kubernete Node Address Range: 172.16.0.0/24 -> 192.168.0.0/24 * Kubernetes Service Address Range : 192.168.0.0/24 -> 10.254.0.0/24 
 
 ゴール
 VNC 踏み台サーバ上のブラウザにて「192.168.0.1:30080」を入力することで、WordPressの画面が表示される 
 
 ICTSC2018 予選: https://blog.icttoracon.net/2018/08/27/ictsc2018-prep01-docker-p2/
  13. 問題例: 構成図 K8s Master & Node K8s Node K8s Node

    192.168.0.0/24 .3 .2 .1 10.254.0.0/24 ClusterIP Range MySQL Pod WordPress Pod kube-dns Pod To: mysql.default.svc.cluster.local:3306 NodePort Service To: 192.168.0.1:30080
  14. 問題例: トラブルの箇所 K8s Master & Node K8s Node K8s Node

    192.168.0.0/24 .3 .2 .1 10.254.0.0/24 ClusterIP Range MySQL Pod WordPress Pod kube-dns Pod To: mysql.default.svc.cluster.local:3306 NodePort Service To: 192.168.0.1:30080 CrashLoopBackOff
  15. 問題例: 解説・想定解法 1. WordPress PodがCrashLoopBackOffしてることを確認
 • kubectl get pod 2.

    WordPress Pod のログ確認
 • kubectl logs wordpress-xxx
 ⇒ getaddrinfo failed: Temporary failure in name resolution ⇒ 名前解決に失敗
 3. kube-dns Pod のログ確認
 • kubectl -n kube-system logs kube-dns-xxx ⇒ x509: certificate is valid for 172.16.0.1, 192.168.0.1, not 10.254.0.1 ⇒ 証明書の Subject Alternative Names が誤っている 4. 証明証を再生成して kube-apiserver を再起動 Kubernetesクラスタの移行手順書は存在しません。アドレスレンジに以下の変更が
 あったことのみ分かっています。
 * Kubernete Node Address Range: 172.16.0.0/24 -> 192.168.0.0/24 * Kubernetes Service Address Range: 192.168.0.0/24 -> 10.254.0.0/24 問題文より
  16. 例年の問題の傾向 • 運営が興味のある技術に関する問題が出る • Docker / Kubernetes • QEMU /

    KVM / OpenStack • 運営目線: • 大会を開くために仮想化基盤を利用 • 仮想化基盤に興味があるから運営がやりたい ➢ トラブルに当たる → 問題にしよう
  17. じゃあ何をどう勉強しとけばいいの? • サーバ構築をやってみる (例. LAMP, LVS, …) • やってみた で終わらない

    ◦ なんでこの設定が必要? • 構築ログを文字でまとめる ◦ 頭の中はメモリ、wikiやブログは外部記憶装置 • もっと楽にするには?を考えてみる ◦ 構築が面倒 → プロビジョニングツール (例. Ansible) ◦ 物理マシンの用意が面倒 → Virtual Machine (例. KVM) ◦ 依存関係の解決が面倒 → コンテナ (例. Docker) • 基本を抑える • 資格取得: 取得よりもそれまでに得た知識が財産
  18. 本番にやること • Slack 等チャットツールを活用し分担して解く • 問題が分からなかったら寝かす • 不明瞭な点は運営に質問しまくる • 他の人が解けるかも

    • 他の問題がヒントになるかも • 一日目と二日目の間にみんなで考える • 切り分けポイントや質問することを考えておく
  19. 懇親会 • 例年、本戦の1日目と2日目の間にある • 貴重な出会いの場 • 同じくらいの年の強い人達がめっちゃ集まってる • 企業がリクルーティングに来る /

    ラフにやってることを聞ける • 次回トラコンの運営になれる! • 伝えたいこと: 懇親会を楽しむのが一番のトラコン攻略
  20. 使用機材から考える攻略 予選 • Vyosを基本に一部Cisco(CSRかな?)っぽい感じ • 知識系(IPアドレスの話,光ファイバーの規格の話) • 実際にconfigを変更する問題とconfigをみて考察する問題半分半分ぐらい 本選 •

    Ciscoの物理機材がメイン(1841,1941.892j,2960) • ここ数回はcisco以外もあるけど毎回出るか?正直わからない。 • Vyosの問題も予選同様に出る。
  21. 当日やることから考える攻略(本選) • 注意事項をちゃんと読む(やってはいけないことたくさんある) • 物理図は配布されるので確認する(配線間違ってないかとかも) • 競技開始と同時にconfigを抜き取って別の場所に保存 • 問題文を読んでそれぞれの担当問題を作る。またそれぞれの問題のslack のチャンネルを作る

    • 私たちのチームは1日目を捨てて論理図作成して頭を整理すること • 2日目までに家でネットワーク機器を大量展開して完全再現する。そして明 日提出する用の解答を作成→寝る • (余力があれば)モニター頑張って持っていくと人権あり。あとは貼るタイプ のホワイトボード