イベント, インフォメーション, お知らせ, 勉強会

これは MySQL Casual Advent Calendar 2015 の19日目です

みなさん、肉の日といえば毎月29日を思い浮かべますでしょうか。
焼き肉が安くなったり、いろいろなキャンペーンを行っている、あの日です。
ツチノコの生息地、大手町のお店でも肉の日にランチ焼き肉が安くなったりしているようです。
MySQL界隈で毎月29日といえば、そうです MySQL用全文検索エンジンMroonga 及び Groonga のアップデート日です。さらに、毎年だいたい02/09にメジャーアップデートを行っています。
現在はVer5系、Groongaは5.1.0、Mroongaは5.10が最新バージョンです。
12/29にはそれぞれまたアップデートが来るのではないでしょうか。
また、MySQL5.7において全文検索機能が入ったということで、いろいろと皆さん試しているのではないか、と思います。

そして来年2016/02/09のに、下記イベントが開催されることとなりましたので、そのご案内を致します!

MySQLとPostgreSQLと日本語全文検索

概要

「MySQLとPostgreSQLと日本語全文検索」は次の2つのことについて紹介するイベントです。

MySQLで日本語全文検索する方法とその利用事例
PostgreSQLで日本語全文検索する方法とその利用事例

私しののめも「DMM.comラボでの日本語全文検索の利用事例紹介」として簡単にお話をさせて頂く予定となっております。

また席に余裕があるようですので、ぜひ皆様恵比寿ガーデンプレイスへお越しくださいませ!
また、MySQLでの全文検索利用事例、PostgreSQL向けのPGroongaの利用事例、pg_bigm利用事例も発表者募集中ですので、ぜひよろしくお願いいたします!

イベント概要
https://groonga.doorkeeper.jp/events/35295
MySQLとPostgreSQLと日本語全文検索
日時:2016-02-09(火)20:00 – 22:00
会場:DMM.comラボ 東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー21F

ICTSC, イベント, インフォメーション

こんにちわ。ツチノコブログ2回目のibuchoです。

このブログのエントリーでも幾つか書かれているのでご存知かもしれませんが、先日の8月29日、30日に開催されたDMM.com Labo ツチノコ杯 第4回ICTトラブルシューティングコンテスト(略してトラコン4)の模様をドキュメンタリータッチでご紹介します。(若干の潤色はありますが、ほぼ事実に基づいております。)

2015年8月29日(土曜日)

08:00 : 朝8時、トラコン4本選会場である工学院大学5Fに設置されたNOCルームに運営学生全員が集合した。2週間前から毎晩夜遅くまでコンテストの準備に追われていた運営の学生達だが、昨夜だけは18:00に作業を終え、今日に向けて十分な休息を取り万全の体調で参加選手を迎える事にしていた。始めに運営リーダの森から本日の予定、担当、シフトの確認、残作業、問題の準備等が伝えられ、各自それぞれの役割に従って会場やサーバ、プログラム、採点表の確認など、おのおのあらかじめ割り当てられている作業へと散っていった。

DSC07399 DSC07397

09:00 : 会場である5Fフロアはさながら嵐の前の静けさであり、案内看板、受付の準備も完了し、あとは出場選手を迎え入れるだけである。

DSC07406 DSC07410

運営学生はリラックスしている風を装っているが、心なしか表情に緊張の色が見え隠れしている。

DSC07544 DSC07538

09:30 : 受付開始と同時に参加者がぞくぞくと入場してくる。各参加者は受付で学校名、チーム名を申告し、運営学生に案内されコンテスト会場へと進む。そして各チーム毎のテーブル上におかれたゼッケンを手に取りコンテストに望む準備をする。チームの仲間と会話し作戦を確認する者、テーブル上に設置されている機器をチェックする者、ブラウザを開き何かを調べ始めるもの、ネットワーク技術の教科書を開き復習をする者など、さまざまである。そしてコンテスト開始10分前には全チームが集合し、ザワザワしながらコンテストの開始を待っていた。

DSC07424 DSC07448

10:00 : 会場正面の演題に運営チームリーダーの森が立ち、コンテストの開始を高らかに宣言した。

DSC07453 DSC07454

コンテストのルール、注意事項などが告知され、続いていよいよ初日午前の問題が出題される。出題は各チームにあらかじめ提供されているredmine上にチケットという形で出題されるため、会場内で問題がアナウンスされるということは無い。各チームは一斉に端末でredmineを開き、チケットとして発行された問題を確認しはじめる。初日午前の問題は以下の3問であった。

Q1. Webサーバを構築してくださいな。

Q2. スイッチ間を冗長化してほしい。

Q3. VPNの構築の件について。

問題文の内容は漠然としている。たとえばQ1の問題文は以下のようになっている。

新入社員「それなんですか?」
上司「これは俺が昔遊んでたサーバさ。CentOSが大好きでね。ちょうどいい、勉強用に使いなさい。まずはWebサーバを構築してみようか」
新入社員「やったーーー!がんばります!」

報告事項 :実際に行ったWebサーバの構築手順

これのどこがトラブルシューティングなのか?と誰もが思うだろう。過去にトラコンに参加したチームにとっては見慣れた問題形式だが、初出場のチームにとっては問題の意図が全くわからず、何を要求されているのか、何と答えると正解なのか混乱したはずだ。通常学校で出されるテスト、資格試験などの問題には必ず回答があり、問題文からどのような知識、解法手順を要求しているかが予測できる場合が多い。学生は問題を読み、授業や講義で学んだ知識を元に問題が要求している回答を探すといった対応をする。つまりクイズやパズルを解く事と同等なのだ。

DSC07471 DSC07467

しかし、実際の現場において、回答のある問題などあるはずがない。トラコンで出題される問題は正に現実に起こっているトラブルや上司や顧客から依頼、指示された作業を実施する様をモデルとしている。この問題形式は運営の学生が独自に発案し作成したものであるが、参加選手にとっては答の無い問題という実際の現場で直面する状況を経験する非常に良い機会であろう。

11:59 : 午前の問題の回答制限時間が近づく。その時、コンテストの成り行きをNOCで見守りながら各チームの回答の採点を行っている学生達がざわついた。15チーム中、1チームだけ3問全部満点の回答を叩き出したチームがいる。

日本工学院八王子専門校チーム「WCDI」である。

WCDI-1 WCDI-2

通常初日午前というのはコンテストの勝手がわからず、問題に取り組むというよりは機器や回答方法などの環境を把握するだけで精一杯であり中々正解を出す事は難しい。実際、他のチームはノーポイントか、せいぜい正解が1問だけだったが、チームWCDIは全問完璧な回答を出して初日午前をダントツトップで駆け抜け、このままポール・トゥ・ウイン、先行逃げ切りをぶちかます勢い。ロレンソか。

13:00 : 昼休みが終了し、各チームが再び所定のテーブルに着座した所で初日午後の問題が出題された。

Q4. ときどきサーバにつながりません!

Q5. 残りのスイッチの設定は任せた!

Q6. Redmineの意図しない挙動の調査について

Q7. 新しい営業所

これまた問題タイトルからは内容が全くわからないが、サーバの脆弱性が攻撃されていたり、あらかじめコンフィグレーションされている設定が間違っていたりといったトラップが仕込まれており、参加選手はサーバ、機器類のログや設定を調査しながら原因を突き止め、トラップを修正もしくは回避しつつ依頼された内容を解決していかなければならない。

午前問題をトップでクリアしたチームWCDIはまたもや4問中2問で満点を叩きだした。しかし、ここで急速にWCDIに迫るチームが出現する。

関西大学大学院チーム「コバゼミ」だ。

コバゼミ1 コバゼミ2

チームコバゼミは前回(トラコン3)から参戦して初出場で優勝を勝ち取った、いわばディフェンディングチャンピオンチームである。前回は学部4年生の関西大学としての出場だったが、チームメンバ中の数名が大学院へ進学し、今大会ではゼミの新たなメンバーを加え大学院チームとして参戦した。チームコバゼミはチームWCDIと同じく4問中2問で満点を叩き出した。しかもWCDIがノーポイントだった問題でも得点を獲得し、いきなりWCDIに肉薄してきたのだ。

17:00 : 初日午後のコンテストが終了。結果的にトップはチームWCDIが死守し、ついでチームコバゼミが5ポイント差で2位に着けていた。問題の得点は5ポイントと10ポイントの2種類が用意されているため、1問の差で同点になるか、もしくは順位が逆転する可能性もある。初日の結果により2日目には俄然これら上位2チームによるデットヒートが展開されるだろうと、運営の誰もが予測しつつ、初日夜に予定されている懇親会へとなだれ込んだ。(出張握り寿司付き)

DSC07683 DSC07714

しかし、初日を終了した時点でトップ2チームのWCDIとコバゼミの背後から静かに忍び寄るチームがあった事を関係者、そして運営さえ誰も気づいていなかったのである。

(後編へ続く)

DSC07774 DSC_8296

iDC, イベント, インフォメーション, インフラ全般, ネットワーク, 製品

7月にJuniper様主催のイベントである「Juniper Cloud Builder Conference 2015」に登壇させていただいた内容を、をASCII.jpに取りあげてもらいました。

成長し続けるDMM.comのネットワーク、その変遷を担当が語る
http://ascii.jp/elem/000/001/047/1047295/
読んでいただけると、DMMの事業スピードに対応するため、Juniperのファブリック技術を用いて頑張って整理拡張をしてきた様子がわかるかと。
Juniper様主催のイベントなので、Juniper機材にフォーカスした内容になっていますが、もちろん他社の機材も使っていますよ。
機会があれば今後もいろいろと発表させていただければと思っています。

ICTSC, イベント, インフォメーション, コラム, ネットワーク, 運用管理

こんにちは!
学生ツチノコのsaiです!

今回はICTトラブルシューティングコンテスト(以下、トラコン)の一日目で出題されたネットワークの問題、スイッチ間の冗長化についてお話しようと思います。

※問題作成者ではなく大会参加者の記事となります。確実な正答ではございませんので、ご了承くださいませ。

問題のシナリオと条件

<大まかなシナリオ>
人員が増加するのでスイッチをもう一台追加することとなった。
現状、既存のスイッチと新たに導入したスイッチ間をUTPケーブル一本で接続している。
そのためか、追加されたスイッチに接続している端末のネットワークが遅くなったりと不安定である。

<条件>
1.スイッチ間の経路冗長化と通信帯域の拡張をする際、ネゴシエーションはしない設定で行う。
2.ポートはFastEthernet0/1と0/2を使用し、トランクポートとすること。

 

問題を解くに当たっての知識

・STP (スパニングツリープロトコル)

@network Cisco・アライド実機で学ぶ様  http://atnetwork.info/ccna3/stp1.html

・アクセスポートとトランクポート

ネットワークエンジニアとして様 http://www.infraexpert.com/study/vlanz2.html

・イーサチャネル

@network Cisco・アライド実機で学ぶ様  http://atnetwork.info/ccnp5/fec07.html

この問題は以上の知識と、ネットワークにおける基礎的な知識があれば解ける問題でした。

CCNAレベルを理解していれば、調べずともこの問題を解けるのではないでしょうか!

トラコンは前回か前々回まで参加する学校等の関係もありネットワーク問題の割合が多く、その難易度も高いものでした。(参加してませんが、VPNとかVPNとかVPNとか)

しかし色んな学校が参加するにあたって、問題もネットワークによるのではなくバランスの取れたものにしたようです。

 

今回の設定について

設定だけで言うと

1.スイッチA、スイッチBのFa0/2をケーブルで接続
2.ターミナルFa0/1とFa0/2にswitch mode trunkchannel-group 1 mode onを両方のスイッチに入力し適用
3.show etherchannel summayを使用し、イーサチャネルの状態を確認
4.pingを相互でvlan1に飛ばしイーサチャネルの疎通を確認
5.copyコマンドを使用し、スタートアップコンフィグに設定を反映

経路の冗長化、帯域拡張、トランクポートの設定は以上で問題ないと思われます。

 

設定の解説

では、順に解説していきます!(4,5は割愛)

1.スイッチA、スイッチBのFa0/2をケーブルで接続

これによってスイッチA―B間は二本のケーブルで繋がれた状態になっています。
しかし、ブロードキャストストームを防ぐため、STPによって一つのポートがブロッキングポートとなるので (RSTPの場合はオルタネートポートと名称が変わります)
二本繋いだけど、ループになっちゃうから一本だけ日頃使わないようにしといた という状態になります。

「なんだよ、それじゃ意味ないじゃん!!」

・・・と、待った待った。実はそんなことないんですね!
STPはループを回避するにプラスして冗長化もしてくれています。

そもそも 冗長化 とは…

まず例としてスイッチとパソコンの間にケーブルが一本あり、それを介してネットサーフィンをしているとします。
もしも、このケーブルが断線してしまったらどうなるでしょう・・・
当たり前ですが、パソコンはインターネットに接続できなくなりネットサーフィンも出来なくなってしまいます!ohᔪ( ᐪᐤᐪ )ᔭNo!

スイッチのケーブルをもう一本増やしてみましょう。
そうすると、ネットサーフィン中に片方のケーブルが断線したとしても、もう片方のケーブルがアクティブ状態となり接続が保たれるようになります!
これが冗長化!片方動かなくなってももう片方が動く!それが冗長化!
つまり冗長化を使用すると、可用性が向上するわけです!
STP以外にもRSTP、ルーターではVRRP、HSRP等、冗長化するためのプロトコルは色々あります。
設定によってはロードバランシング(負荷分散)も実現できる為、ネットワークを常時止めないという点においてとても重視される項目になります。

 

つまりは、日頃一本ケーブルを使わないだけで、片方が断線なりした場合はもう片方が肩代わりするわけです。便利ですね!
ということで、とりあえずの冗長化はケーブルの接続だけでOKです。

 

2.ターミナルでFa0/1とFa0/2にswitch mode trunkchannel-group 1 mode onを両方のスイッチに入力し適用

前者のコマンドを使用することにより、任意のポートをトランクポートに設定することが可能になります。
これによって複数のVLANの通信をトランクポートを通じ橋渡しができます!

後者のコマンドはイーサチャネルというものの設定をしています。
これは「複数の物理ポート」「一つの論理ポート」に束ねる技術です!
束ねたインタフェースをポートチャネルといい、ポートチャネルで接続する事で通信帯域を増やす事ができます!
STPでは片方のケーブルは日頃使わない状態になっていましたが、この設定を施すとケーブル二本の通信帯域を有効的に使用できるというわけです!
因みに、mode onの部分はネゴシエーションしない場合の設定となっておりますが、両方のポートでmode onの設定を入れておく必要があります。

 

この問題の設定自体は以上で終了です。

ですが、実際に反映されているか、自分の思ったように行われているかの確認のために以下を行っています。

3.show etherchannel summayを使用し、イーサチャネルの状態を確認

このコマンドを使用するとポートチャネルとそれに属しているインタフェースが見れるようになっています。

 

 

(´-`).。oO(showコマンド、ほんと便利だ)

 

まとめ

この問題では、「ネットワークが遅くなったりと不安定である」というのがトラブルの症状となっていました。

問題文の中に「冗長化と通信帯域の拡張」と対処すべき項目が記述してあったので、チームによってはスムーズに終わったのではないでしょうか。

また、今回とりあげられている冗長化はネットワークやサービスを止めないために重要であると思います。

必要となる場面は多岐にわたるので、解けなかった!知らなかった!という方は勉強してみてもいいかもですね!

ICTSC, イベント, インフォメーション, ネットワーク, 運用管理

こんにちは、whywaitaです。

「DMM.com Labo ツチノコ杯」第4回ICTトラブルシューティングコンテスト にて運営委員を務めさせて頂きました!

「DMM.com Labo ツチノコ杯」第4回ICTトラブルシューティングコンテスト(以下、トラコン)では様々な機材や技術を用いた上での運営を行いました。

今回はその中で、サーバ周りの技術をご紹介したいと思います!

ansible

今回は物理ホストサーバの上に、vmware社のvSphereを構築し、その上で仮想ホストを管理していました。問題用サーバ・運営用サーバ・DMZ用サーバ・その他様々な用途のサーバが立っており、最終的には350台弱のサーバが起動していました。このホスト群を上手く操作するのはとても大変です。問題を出す直前で何らかの仕様変更が発生したり、事前にやっておくべきであった操作を完全に忘れたまま放置していた事もありました。

この問題を対処するために我々が採用していたのが、ansibleです。

今回ansibleでは、以下のような作業を行いました。(あくまで一例です!)

  • チーム毎にログインパスワードの変更
  • ntpdやiptablesなどの必要なミドルウェアのインストール
  • 参照するリポジトリを日本のミラーサーバに変更
  • 参加者が作業するサーバに対して、運営の作業ログ削除
  • DHCPにて割り振られていたIPアドレスを利用して、そのままstaticなconfigの設置

特に、「問題用ホストを問題として出せるように調整する」作業に大きな効果を発揮しました。

問題によっては1チームに3台のホストを提供していることもあり、今回参加して下さったチーム数が15チームのため、全部で45台分その問題用のホストがあることになります。このホスト群に対して同じ動作をする必要があるのですが、その際にサッと書いたansibleのplaybookを書く事で、全台に対して同じ動作をすることが保証された状態で設定の変更を反映することができました。

ホストの大量展開

また、多くのホストを操作する事が出来ても、そもそも構成を管理するホストが無ければ意味がありません。通常であれば長い時間をかけて少しずつホストが徐々に増えていくのかも知れませんが、今回のトラコンではそのような事は出来ず、一度に数十台のホストを用意する必要がありました。

その解決策として、vsphere_guestというモジュールを用いて、大量展開を行いました。これを用いる事で、特定のテンプレートを基に複数台のホストを自動で用意する機構も作成しました。

この機構により、問題用のホストを作成した後にそのホストをテンプレート化、チーム数分展開を行うことで、各チームごとに差異が発生しないまま問題を出すことが出来ました!

事前準備期間のansible

当日は複数ホストに対する操作が多かったのですが、当日までの期間には構成管理ツールとしての使い方を行っていました。

GitHub上でのPullRequest(通称PR)ベースでの開発を行うことで、一定の品質を保ったplaybookの開発を行うことが出来ました。

PRの様子
また、GitHubへのPRをトリガーとして、jenkinsを用いた自動テストを行い、その結果をslackに通知していました。これにより、テストが失敗した時のみjenkinsを確認すれば良いので大変便利でした。近年はChatOpsと呼ばれるチャット基盤とオペレーションを繋げる試みが話題ですが、その便利さには本当に驚かされます。

jenkinsの結果がslackに通知されている様子1
jenkinsの結果がslackに通知されている様子2
これらの機構を使う事により、安定かつ暖かみの無いplaybookの制作を進めることが出来ました!

playbookのオープンソース化!

最後に、トラコンの過程で出来たplaybookがどのようなものになったのか、気になりませんか?

なんと…作成したplaybookが、先日オープンソースとしてGitHub上にて公開されています!

ictsc/ictsc-playbooks

構築期間中、とある社会人の方に競技後公開する話をした所、「太っ腹すぎない?」と心配されてしまいましたが問題ありません!再利用性があるように(急いでいて出来ていない部分もありますが)制作したつもりですので、ライセンスの下ご自由にご利用ください!

まとめ

学生の身分で約350台のホストを一斉に管理することは中々無いので、今回は貴重な経験を積む事が出来ました!

これからもトラコンは続きます!大量のホスト管理に興味の出た方は、是非運営参加もご検討下さい!

PAGE TOP