イギリス訪問記 – York探訪編

IMG_4112

去る7月上旬になりますが、1週間ほどイギリスへ旅行に行ってきました。大きな目的が2つあったのですが、そのうち1つであるツール・ド・フランスについては既に「イギリス訪問記 – ツール・ド・フランス観戦編 #TDF」のエントリにまとめました。今回は、その中で書ききれなかったYorkの町についてのお話を「Yorkについて」「今回訪ねた所」そして「Yorkの街並み」の3節に分けて改めて書こうと思います。

Yorkについて

「アメリカのNew Yorkじゃなくて?」と言われそうですが、実はNew YorkのYorkは、EnglandのYorkから来ています。また、Yorkの歴史はEnglandの歴史と言われるほど古い町でして、2000年以上前から様々な営みがあったようです(See also: Brief History of York)。

交通は、Londonからですと主に北の玄関口であるKing’s Cross駅から列車が出ており、2〜2.5時間程度で到達する事ができます。本数は日中なら1時間に1本以上あり、交通の便もそれなりに良い所です。町も小さく、また趣き深くまとまっており、徒歩で周遊しやすい場所となっています。宿泊場所は、観光地である事からとても充実しており、駅前のホテルから、少し歩いた所にはB&B(Bed and Breakfast, 日本で言う民宿)もあり、予算に応じて多彩な選択が可能です。

僕らは、当初はYork滞在の目的をツール・ド・フランス観戦のみを考えていました。しかし、観戦した次の日にまた移動は大変そうだった事と、調べていると町としていい所そうなのがわかりまして、1日延泊して更に町を楽しむ方針に変えた経緯があります。結果、これは非常に良い選択だったと思い起こしている所です。

今回訪ねた所

ざっと書き並べてみます。順不問です。

York Minister – 京都に行ったら清水寺に行くでしょう?ってくらい定番です。それにしても天井が高い。ただ、大ステンドグラスは、保存工事のため眺める事ができなかったのが、少し残念です。入場料は£15です(1年間有効)。

IMG_4074

National Railway Museum – 鉄道発祥の地イギリスの国営鉄道博物館です。御料車を初めとした歴史的に貴重な車両が触れられる距離で展示されています。展示室には何と喫茶スペースまでありまして、さすが紅茶の国 イギリスだと思いました。また、日本から0系新幹線もやってきておりまして、日本の技術ここにあり!と感じる事もできます。訪ねた日の入場料は何と「無料」。ただ、Donationをお願いされますので、数ポンド払いましょう。

IMG_4252

Treasurer’s House – お屋敷でして、現在はNational Trustが管理・運営しています。地下にはティールームが、上階は貴重な調度品とともに展示されています。また、各部屋にボランティアの人がおり、部屋の事から一つ一つをとても丁寧に説明してくださいます(※1)。入場料は£6.36です(カフェは入場料無し)。

IMG_4174

Yorkの街並み

IMG_4144

中心部は城壁で囲まれており、一部は今でも自由に歩く事ができます。訪問した日はとても良く晴れてよい風が吹いており、気持ちよいひとときを味わう事ができました。

また、古い街並も非常に趣き深いものがあります。あちこちにPubがありまして、酒好きなら1年いても飽きる事はないでしょう。いくつか入ったPubの中で、特に”The Old White Swan“が良かったです。ビールはうまいし、食べ物はうまいし、そしてサーバの前で接客しているお兄ちゃんがとってもCuteで感動しました。明るくハキハキと、そして丁寧にもてなせる人って、漫画の世界だけの存在かと思っていました。

あと、屋台の生搾りレモネードがとてもおいしかったのが印象的でした。旅行中、後にも先にも、ここのレモネードを越えるものは遂に見つける事ができませんでした。Yorkにいると、イギリスの飯がまずいのは、日本人がちょんまげをつけていると思われているくらいいい加減な話だなと感じずにはいられませんでした(※2)。

そして、Yorkは自転車と積極的に共存していて、道路脇の各所しっかりと自転車専用レーンが整備されていました。また、自転車のマナーもとても良く、互いに気持ちよく過ごす事ができる空間となっていました。ここに、自分の自転車を持ってきて走ってみたかったですね〜(See also: Cycling in York)。

想像以上に良かった

ここまで、York探訪のお話を「Yorkについて」「今回訪ねた所」そして「Yorkの街並み」の3節に分けてお話ししました。イギリスには各所に良い観光地があり、ついついそこへ行きがちです。そんな中で、Yorkは町が小さい割に非常に趣き深い体験ができる、とても周遊しやすい良い観光地である事がわかりました。また、ツール・ド・フランスの観戦の機会が無ければ、このような出会いはなかったかもしれません。

この記事をご覧になられる方に、ひょっとしたら検索サイトからイギリスの観光地を探しにこられた方もいるかもしれません。Yorkには、ここには書ききれない事、そして僕が知らない良さがまだまだあります。そんな方にも、この記事がちょっとした偶然を提供できる機会になれば幸いです。

IMG_4092

※イギリス訪問記 一覧

※1: 英語のリスニング力を試されている感ありました。

※2: 後日Cottswoldsに行く観光バスの中で、添乗員さんが「イギリスの食事がおいしくなったのはロンドンオリンピック頃から」とのことで、つい最近のようです。イギリス在住経験のある相方も、確かにそう思うと言っていました。

イギリス訪問記 – ツール・ド・フランス観戦編 #TDF

世界最大の自転車ロードレース「ツール・ド・フランス」(Tour de France, 以下ツール)。2014年は、ニバリ選手の総合優勝で幕を閉じました。フルーム選手やコンタドール選手が次々とケガで棄権する中、特に後半は素晴らしい走りを見せていたことに、新しい勝者の登場を感じずにはいられませんでした。

さて、自転車が好きな方なら、人生に一度でいいから、ツールを観に行きたい!と思われるのではないでしょうか。ええ、僕も自転車通勤をはじめた2008年からずっとそう思って来たのです。

ということで…

DSC_0624

来ちゃいました!

2014年の第2ステージ スタート地点のYork(ヨーク)です。本当にやってきたんですよ!!YorkってEnglandじゃないかと言われそうなのですが、今年の初戦〜3日間はEnglandで開催されることになったのです。あと、他にも用事があったのでEnglandで観る事にした背景もあります。ここまで、日本からほぼ丸1日かかりました。この写真は現地時間21時頃に撮ったのですが、緯度が高く夏なためまだ日が沈んでおりません。

今回は、スタート地点のYorkを拠点に、時間が許せばゴール地点のSheffield(シェッフィールド)を目指します。Yorkの町そのものについては、気が向いたら別途書きます(書きました→「イギリス訪問記 – York探訪編」)。

ツール・ド・フランスがわが町にやってきた!

ツールが自分の町にやってくる事はとても喜ばしい事なのだそうで、フランスでは町をあげて歓迎するのだとか。海を挟んだ隣国EnglandのYorkもその例に漏れない歓迎っぷりです。

IMG_3219

建物のほぼすべてにツールを歓迎する飾りが施してあります。Boots(イギリスのドラッグストアチェーン)のロゴまでツール仕様です(笑)。

IMG_3283

お世話になったB&B “Crescent Guest House“さん(Bed & Breakfast, 日本で言う民宿)でも、親父に開口一番「ツール観に来たの?そりゃいい!うちの目の前も走るしね〜」という話に。地元のおじさん・おばさんでさえ当たり前のように歓迎しているこのムード、最高ですね。ただ、続いて「さっきカヴェンディッシュが転倒したよ…」って聞いた時にはびっくりしました(※1)。

スタート地点ではパレードを楽しもう

先ほどもお話ししましたが、YorkではB&Bのある通りの目の前がコースに設定されています。そのため、朝食を食べた後すぐに観戦に向かう事ができる、素晴らしい立地です。観戦とは申しましても、リアルスタート前のパレード走行の区間ですので、選手たちを暖かく歓迎する形になります。以下の写真は、現地時間 朝6時にB&Bの玄関からコースを眺めた様子です。

IMG_3299

Yorkに来る前に調べてわかったのですが、ツールではレース2時間前からスポンサーのパレードがあるのです。ここではツール観戦中おなじみのスポンサーの車両が次々と40km/h程度の速度で通過して行きます。その時に、ノベルティを撒いて行くんですね。大人はマナーよくいただいちゃいましょう〜(※2)

IMG_3477

朝9時からパレードが始まり、断続的に10:30頃まで続きます。いやー、すごい。本当にすごい。そして、人もすごい。どこの山岳ステージかと思うほどの人の数です。それにしてもおまわりさんは余裕ですね。ハイタッチしてるし。

IMG_3617

選手が来るまでの2時間は、パレードの写真を撮ったり、オフィシャルグッズ移動販売車にグッズを買いに行ったり、地元のFMラジオ “BBC York“を聞きながら待っていました。BBC Yorkではツール特番が組まれていまして、リポーターが商店街の人たちに「いやー、楽しみですね!」というノリでインタビューをしていました。こうやって観戦できるのは現地にいるからでありまして、日本でテレビを通じて観戦する事に比べたら贅沢なのかもしれません。

そうしていると、11:10頃に競馬場をスタートした選手の集団がやってきました。

IMG_3757

これがツールなのだ、先頭にフルームもいた!と感慨に浸りたくなる所なのですが…彼らは40km/h程度であっという間に通過して行きます。写真なんか撮っている場合ではありません。これはいけません!

通過後、時間に余裕があったので、フィッシュ&チップスを買い列車に乗り込んで、ゴール地点であるSheffieldへ移動を始めました。

ゴール地点では戦いを楽しもう

ツール 2014年 第2ステージは、リエージュ〜バストーニュ〜リエージュ並みの厳しいコース設定でして、獲得標高差は何と3,400mとヘタな山岳ステージ並みです(「獲得標高差3400mのハードな一日 ニーバリが区間とマイヨジョーヌを射止める | cyclowired」より)。そうなりますと、山岳ステージ同様、集団もばらけることが予想されます。当然、観戦もより長く楽しめる可能性が出るのです。

YorkからSheffieldまでは列車で1時間程度。なんと、先回りする事ができるのです。素晴らしいですね。今度こそはカメラを降ろしてじっくり観戦することにしました。僕らは、最後の急坂Jenkin Roadを越えた後の下り〜残り3kmあたりで観戦する事にしました。市内の移動は、Sheffield駅からSupertram(路面電車)に乗ってスムーズにこなす事ができます。

IMG_3821

ここでは、公式アプリで順位と先頭の位置を確認しつつ、BBC Channel 5にラジオを合わせて観戦。70km/hは出ていると思われる速度で、次々と選手が下って行きます。その様子はまさに壮観。ここで、ニバリが劇的なスパートを決めてステージ優勝を飾った事はとても印象的でした。今思えば、総合優勝を予感させる出来事でした。

また、予定通り集団はばらけていまして、Yorkでは逃してしまった観戦チャンスをじっくり堪能する事ができました。特に、選手の体格をしっかり確かめる事ができたのは大きな収穫です。まるで、美術館に展示されている彫刻のようでありました。特に、カンチェラーラ選手のフォームは、獲得標高差3,400mを本当に走ってきたのか?と考えてしまうほど、本当に素晴らしいものです。見とれてしまいます。

IMG_3883

また、唯一の日本人選手である新城選手を目にする事もできました。遠い遠いヨーロッパの地で、アシストとして毎年活躍している姿は、本当に素晴らしいし、日本人として嬉しくなります。一方、素人の僕には想像できない苦労、そして喜びがあるのでしょう。ただ、声援を送ろうとしたら間に合わなかった事が少し心残りです。

IMG_3918

こうして、僕らのツール観戦は終わりました。混雑がひどくなる前にSupertramに乗り、Sheffield駅でコーヒーを飲みながら休憩しつつ、列車でYorkに戻りました。

これから観に行かれる方へ

アドバイスと言えるほどのことはできないのですが、僕らが留意した4点をお伝えします。

  1. 観戦してみたい場所をテレビ中継をもとに当たりをつける
  2. 行きたい場所の交通・宿泊事情を良く確認する
  3. 移動時間にかなり余裕を持つ
  4. 町とともに楽しむ

1は、だいたい速度が落ちそうな所、人があまり混み過ぎない所のヤマを張るために調べました。実際、僕らはそれほど混雑には巻き込まれずに無理なく観る事ができました。

2は、慣れない土地に移動するため、どうやって行く事ができるか、頻度等はどうかを調べていました。Yorkは交通事情が良い所(London King’s Crossから列車で2時間程度)であったため、選択しやすいところでした。また、観光地であったため食事や宿の確保も特段の苦労はありませんでした。経路や通過時刻は公式サイトや地元特設サイト等で案内されていますので、よく確認してみてください。

3は、海外旅行全般に言える事ですが、日本のように定時でスムーズに動けるとは思わない方がいいです。計画時は遅れた時の事を考えて1〜2時間のマージンをとって列車の指定席をとっていました。日本からYorkまでは遅れもなくスムーズでしたが、SheffieldからYorkに戻るときは、列車がかなり遅れているのに”On Time”と出ていて、カルチャーショックを受けました。

4は、そうしたほうが僕らは楽しかったです。ステージ開催前後の、ツール開催に賑わう町をじっくり楽しんでみてはいかがでしょうか。観戦地=観光地だとより良いです。実は直前、ある事情でLondon市内観戦をやめてYorkに延泊する事を決めたのですが、結果的にそうしてよかったなと思っています。

正直な感想

以上です。

…と言いたい所ですが、ツールが終わった今だから改めて。

「一体」となって観戦するのが、ツール・ド・フランスなのだと感じました。一体とは、生で観戦することを通じて、テレビ中継を観ていてはわからない現地の空気(町・メディア・そして選手本人達)を肌で感じる事です。どのプロスポーツでも基本は一緒でしょうが、特にツールはそこに住む人たちが一体となって祭りとして盛り上げる点がより凄いのです。もちろん、自分自身もそのひとりとなる事ができるのです。

また、観戦する場所によって、体感できる物事がまた違います。今回は街中でしたが、田園地帯なら大自然とともに、山岳ステージならゆっくりと登る選手達をじっくりと応援する事ができるでしょう。BBCの中継では、山の中でテントを張って当日を待っている人たちの模様も伝えられていました。これほど多様な観戦ができるプロスポーツも、珍しいのではないでしょうか。

IMG_4142

ここまで、いつかと夢見たツール・ド・フランス観戦について、現地の模様をまじえた観戦記としてまとめてみました。訪ねた町と一体となって楽しめる事を、少しでもお伝えできていたら幸いです。

「皆さんもぜひツールを観に行ってみて!」と言いたいのですが、開催場所がフランスまたはその周辺と、日本から簡単に行く事はできない距離にあります。また、時間も、お金もかかります。だからこそ、観戦できた時の感動は何事にもかえられないものがあるのかもしれません。そして、僕らがその感動を体感できた事は、本当に恵まれていたのだなと実感する、今日この頃でありました。

IMG_4860

※イギリス訪問記 一覧

※1: イギリスではウィギンス選手が出られない事への同情と、カヴェンディッシュ選手の転倒を残念がっていた空気がありました。カヴェンディッシュ選手は地元でのゴール前で転倒・リタイアでしたから、本当に辛かったでしょう。

※2: English Gentlemanは確かに存在しまして、こぞってノベルティを取りに行くのは子供だけでした。この事は、イギリス滞在中に終始感心する出来事でした。

房総半島にあじさいをゆっくり鑑賞できる場所がありました

先週末、房総半島の大多喜町にある「麻綿原高原(まめんばらこうげん) 妙法生寺 天拝園」へ行ってきました。

6月〜7月は首都圏各地であじさいが咲いていますが、なかなかゆっくり鑑賞とはいかないもの。場所によっては、60分待つような所もあると聞きます。そんな中、今回足を運んだ麻綿原高原は、心行くまであじさいを観賞できる、素晴らしいスポットでした。そんな話を「あじさいの山」「眺望も抜群」そして「交通について」の3点に分けてお話しします。

filmscan933

あじさいの山!

相方と「週末、どこに行こう?」と話していたとき、何気なく房総半島を目指す事になり、そしてたまたまあじさいが咲いているスポットがあると聞いてたどり着いた麻綿原高原。

驚いた事に、お寺の周りはあじさいの山となっていました。

filmscan936

そして、人もそれほどいません。心行くまで、あじさいを鑑賞する事ができます。もちろん、写真撮影にもじっくり取り組む事ができます。あまり深く考えずに、フィルムをあまり持って行かなかった事を少し後悔しました…。

filmscan924

なお、お寺にはちょっと面白いものがあります。ぜひ、この目で体験してみてください。

眺望も抜群

あじさいばかりではなく、眺望も抜群です。お寺の上に行きますと、晴れていれば勝浦や太平洋を眺めることができます。

IMG_2211

この日は梅雨時であったのにも関わらず、素晴らしい青空と海を眺める事ができました。ちょっと時間がずれていると、夕立にあっていた可能性があったので、本当に運が良かったなと思っております。

交通について

さて、問題は交通です。これだけ空いているのは、簡単には行く事ができないからとも言えます。公共交通機関ではなく、自家用車で行く事がほぼ必須であり、さらにここは山の中であるためそれなりの山道を走り抜けなければなりません。

私は葛飾区のレンタカー屋さんからここまで、京葉道路経由で順調に移動して3時間弱かかりました。また、この日は途中の道が土砂崩れのため遠回りを余儀なくされました。また、遠回りした先も、それなりの険しさの道でした。そして、山道の日陰はたいてい路面がぬれていますので、速度を出し過ぎないよう気をつけて走行する必要があります。

そのため、運転に不慣れな方は天候が荒れるとわかっている日はやめておいた方が無難です。ただ、状況が許す時であれば、この風景をぜひ他の方にもお楽しみいただけたら嬉しいな〜と考えています。

おわりに

ここまで、房総半島のあじさいスポット「麻綿原高原」について、3つの観点でお話ししました。首都圏からそれなりの時間と道の険しさをクリアしなければなりませんが、それに見合った価値は充分にあります。また、写真撮影が好きな方は、あじさいをじっくり撮影するチャンスです。

今年の見頃は、7月第2週、そう、このブログを投稿した今日あたりです。ぜひ、行楽先の候補として検討されてみてはいかがでしょうか。

filmscan922

July Tech Festa 2014へ行ってきました #techfesta

今日は、July Tech Festa 2014に足を運んできました。ITインフラに関するソフトウェアや運用技術の話ばかりではなく、知見として獲得しておきたい他の分野に置ける開発のベストプラクティス等も聴く事が出来ました。

基調講演の「Serverspecに見る技術トレンドを生み出すヒント」では、Serverspec開発にあたってどのような事を考えていらっしゃっていたのか伺えた、貴重な機会となりました。

「インフラエンジニアのための次世代プロトコル入門」では、次世代プロトコルの導入はもう迫ってる現実であり、必ず来る未来である趣旨の話であることを確認させられる、ちょっとヒヤッとするセッションでした。

「Contrailを用いたSDI/NFVの実現」では、Interopよりもここ最近のネットワーク関連のキーワードを掘り下げるよい機会となりました。同時に、ネットワーク関連の話は本当に難しくなってしまって、OS・ミドルウェアレイヤーと同時に追いかけるには難しいのかなと思い始めています。

「フロントエンドで普及が進むビルドツールたち ? Grunt、gulp ほか」では、gulpを使ったWebページ・フロントエンド制作の最新のベストプラクティスを学ぶ事ができ、かつ自分の知識が化石化し始めている危機意識をもつ機会となりました。

それでは、今回もノートをアップしておきます。

概要

★今年もやります!JTF2014!!★
皆様,今年もインフラエンジニアのための祭典,July Tech Festaを開催する運びとなりました。今年は6/22(日)開催です。昨年は300名超のご参加をいただき,技術セミナーをはじめ,数々のセッションが大盛り上がりとなりました。今年のJTF 2014は,セッションなど更にパワーアップし,昨年以上に熱く開催されます!テーマは「インフラ・テクノロジーマップ2014 〜明日を楽するために今日自動化を頑張るエンジニアの集い〜」とし,まさに今年の全貌が見える,旬のインフラ技術が結集します。ぜひご参加ください!

★イベントの詳細★

イベントの詳細は次のURLでご確認下さい。

http://2014.techfesta.jp/
  • 弁当
    • A会場にて頒布
    • 13:00まで頒布
    • 食べるのはA会場 or 食堂にて
    • 指定のゴミ箱へ

Serverspecに見る技術トレンドを生み出すヒント

宮下 剛輔 さん

  • 技術トレンドのキャッチアップ

  • Deckset でプレゼンしてる

  • 今はほとんどCookpadで仕事をしているらしい

  • 本セッションのインフラの定義: OSからミドルウェアといったソフトウェアレイヤーを指す言葉

  • 最近のトレンド
    • Chef
      • 4, 5月に立て続けに本が出た
      • USでは2014にPuppetのシェアを超えたらしい
    • Ansible
      • Chefへのカウンター (複雑さ、大規模さへのカウンター)
    • 仮想化関連
      • Vagrant
      • Docker (2013–03くらい Serverspecと同じくらい 仮想化以上の意味があるものではあるがとりあえず SEE Also:WEB+DB Press Vol.81)
    • テスト駆動インフラ/インフラCI
      • Test Kitchen
      • Serverspec
      • WEB+DB Press Vol.80 に特集記事があるので読んでね
    • Immutable Infrastructure
  • テスト駆動インフラ/インフラCI
    • 概念自体はあった
      • アプリケーション開発の手法をインフラ構築に応用する。
      • 2012年に @riywo さん、 2007くらいに自身でも考えていた。
    • GitHubを利用したワークフローにまで広げられる
  • Serverspecとは
    • 2013–03末にリリース
    • 名称は正しく! Serverspec, serverspec, SERVERSPEC のどれか。1つめは現状、2つめは旧です。気をつけてね!人の名前間違えないのと同じように、
  • Serverspec背景
    • なぜ生まれたの?
      • Puppetで構築は自動化できた→でもExcelベースのチェックシートでの目視をやめたい・自動化したい
    • Assurerの誕生
      • 2007年に作ったPerl製テストフレームワーク
      • プラグイン拡張可能
        • Plaggerの影響
        • Filter, Format, Notify, Publish, Test
      • make test でテスト実行, TAP形式で結果を出力
        • CPAN AuthorなのでPerlでのテストのやり方を踏襲した
      • 敗因
        • 振る舞いをテストした
          • 状態テストよりも要件が複雑化する
        • 詰め込みすぎて更に複雑になった
          • フェイズ分け, プラガブル, 分散処理, シェル
        • Serverspecほどコンセプトが明確ではなかった
          • 自分すら使わなくなった…
    • Assurer以後
      • 思い返しても積極的に何かしようともしなかった
      • マネジャをやっていた事もあり若干現場から距離を置くようになりあまり触らなくなった
    • またPuppetを触り始めた
      • 以前書いたものがレガシーコードになっていた…(あの時はベストプラクティスがなく、今の状況に合っていない。)
      • リファクタリングしたい→当然テストも必要
    • CI環境を整える
      • LXCコンテナでテスト。コンテナをさくっと作れるPuppetマニフェストを書いた。 (でもDockerが出てきて無用になってもた)
    • テストツール探し
      • Puppetはrspec-puppetくらししかない。しかしモジュール化されていない。使えない状況。
      • Chef周辺の方が充実。
      • 上記は実際のサーバの状態をテストする訳ではない。
    • Serverspecの登場
      • 同僚(@hibomaさん)のLXCコンテナをテストするコードをRSpecで書いていた。パクって汎用的にした。
      • 1日でプロトタイプを作り、次の日にgemを公開。
    • 初期
      • 複数OS, バックエンド切り替え対応など、色々入ってきた。
      • いろんな人を巻き込んだ。
        • ちょっとした隙を作る。
    • 今後
      • v2.0
        • 作業中
        • 拡張しやすくするためのリファクタリングが中心
        • 表面上はあまり変わりません
  • Serverspec認知度
    • Black Duck Open Source Rookies of the Tear 2013 にて、Docker, InfluexDB, Appium と並んで受賞。
    • Thought Works Technology Rader 2014にて、Provisioning Testingの項目で出てくる。
    • Rubygems.orgにて30万DL (参考:Chefは400万)。
    • 雑誌 WEB+DB PRESS Vol.75,76,80,81
      • @naoya_ito さんの推しあってのこと
    • 書籍
      • 5冊ほど
    • 海外の反応
      • Adam Jacob さんなど
      • ドイツ
    • ChefConf で発表した資料
      • Puppet のカンファレンスではRejectされてしまった
      • ChefConf で話せるのは認知されてきたんだなと思った
    • Sensu+Serverspec って話もあるらしい
  • Serverspec成功要因
    • ワールドワイドで認知された経緯
    • 能動的な要因
      • 別領域で成功しているプラクティスを持ち込む (今回は特にソフトウェア)
        • テスト駆動
        • CI
      • 同じ用語を用いるとイメージしやすい
        • テスト駆動インフラ
        • インフラCI
      • 名前
        • Server + RSpec と直球
        • 類推しやすい
        • 覚えやすい
      • 英文ドキュメント
        • 日本国外で広く認知してもらうためには重要
        • README, serverspec.org などは最初から英語で書いた
      • 既にメジャーになっているものに乗っかる
        • Puppet, Chef と言ったキーワードをちりばめる
        • Puppet ,Chef の中の人に拾われて広まったかと思う
      • ドキュメントのわかりやすさ
        • リーチャビリティあげるだけではダメ。
        • 見てすぐにわかる、斜め読みしただけでわかるように。
      • ツール自体のシンプルさ
        • そのものがわかりやすいことが重要。
        • テストに特化
          • 構成管理・VMの操作をは省いた
      • 他ツールとの組み合わせ
        • busser-serverspec
        • vagrant-serverspec
      • Agent less
        • テスト実行する環境でRubyで動けば良い
        • テスト対象はSSHだけあればいい
      • とりあえず動かせるような環境で
        • サーバに色々入れるの嫌ですよね (わかります)
        • RHELでサポートできるバージョンで使えるようにしておいた
    • 技術トレンド要因
      • chef界隈テストの盛り上がり
      • JenkinsやCI as a Serviceの普及
      • GitHubの普及
  • まとめ
    • 欲しいもの、面白いものを自分のために作ろう!!!そして公開しよう。
      • (人類の技術発展のための無償開発、というスタンスではいいものはできないよね。)
    • 技術トレンド生み出す近道はない
      • 少なくとも自分は知らない
    • その積み重ねが素晴らしいものを生み出す事につながる
      • 自分が作って公開したものは、小さなものを含めて100ほどある。

インフラエンジニアのための次世代プロトコル入門

中島 博敬 さん

  • スライドは後で公開します

  • インフラエンジニアの仕事
    • 上も下も知る
    • 未来を見据える
  • 現状
    • HTTP, TCP, IP
      • ずいぶん変わってない
      • 動いているものを変更するな。変えるのは大変だ。
    • Web
      • 非同期通信の台頭
  • なぜ次世代プロトコルなのか?
    • 接続環境の変化・ページのリソース数・Webアプリケーションのインタラクティブ化
    • 遅延がWebサービスの収益にリンクする
    • HTTP/1.1
      • 接続の度のヘッダ、無駄だよね!
        • コンテンツ圧縮はできるけど、ヘッダはできない。
        • こまい通信が増えると最悪だね。
      • 「黒魔術」による解決。
      • それも限度がある。
  • HTTP/2
    • SPDYからの提案をベースに議論を開始
      • CRIME攻撃の問題を解決
    • とにかくオーバーヘッドを減らす
    • 全二重通信 (Push)
  • TCP Alternative
    • QUIC
      • SPDY – Head Line Blocking の問題
      • だからUDPベース
      • 1RTTで接続
      • Forward Error Correction – パリティ技術
      • Packet Pacing – Conguision Control (UDPの弱点を補強)
      • Multi Path – ハンドオーバーを0RTTで
  • TCPを既存のネットワークに影響が出ないように変えて行く取組み

  • TLS
    • OpenSSL 悲しい出来事 2つ…
  • IPv6
    • 対応は 日本で3.49, 米国でも7.97% 泣ける
    • Azure 米国リージョンの IPv4 のアドレスが枯渇 (65万個 使い果たした)
    • IPv4 のアドレスの枯渇の問題は既に発生している
    • fail2ban は v6 対応してなくて泣いたとか
    • 新サービスから対応しよう
  • ハイパフォーマンスブラウザネットワーキングもあわせて読みましょう

  • 興味があるプロトコル、一つはじっくり掘り下げてみよう。

  • 次世代プロトコルの導入、もう迫ってる現実だ!必ず来る未来である。

Contrailを用いたSDI/NFVの実現

有村 淳矢 さん

  • ShowNet構築の気分的な疲れが残ってる…(汗)

  • Contrailとは?
    • SDNプラットフォーム ソフトウェア
    • Open vSwitchを使って…という議論があるけど、それそのものだよ。
    • コントリビュートできます
  • プレーンの分離
    • OLD WAY
      • Managerment, Control, Service, Forwarding Plane が内在し、各機器が自立分散して動いていた。
    • NEW WAY
      • コントローラを用いてこれらを集中管理。
  • Contrail
    • 5つのコンポーネント
      • Configuration Manager
      • Collector
      • Web UI
      • Control Plane Node
        • BGPベースのコントロールプレーンを管理
      • Compute Node
    • オケストレータ
    • SDNコントローラ
    • XMPPでメッセージをやりとりしている
    • 大規模にスケールするクラウドサービスを実現可能
      • MPLS VLAN のように
  • OpenFlowとの違い
    • 集中管理している所は同じ。
    • 既存IPネットワークにも情報をフローベース(IP, Port)で注入 コントローラが膨大な情報をもっている
      • 機器に負荷をかけずにトラフィックを切り替えられる
    • オーバーレイモデル(Contrail)だと細かいものを太くして自律分散している
      • 細かい制御が難しくなる
  • NFVとSDN
    • NFVとSDNは完全にイコールでは結ばれない
    • NFVとSDNを絡めて使う事でより良くなる
    • OSの部分だけ抜き出して仮想化するのがNFV
  • Contrailを用いたSDNサービス
    • オーバーレイ クラウドデータセンター
    • IaaS & VPC, Seamless MPLS Datacenter
    • サービスエッジ, NaaS VPN GW
      • 末端のセキュリティ対策をデータセンター側で移譲させてしまう
      • (CATVインターネットとかだといい感じっぽそう)
  • SDN時代のデータセンター・アーキテクチャ」も参照

  • Spine-Leaf のメリット
    • 遅延・ジッターのレベルが一定 (輻輳しなければ)
      • Webアプリケーションのネットワークパフォーマンスが安定する (Hadoopとか)
      • 論文もあるよ
  • VXLAN GW (ToR)スイッチ
    • VXLANトンネルを経由してデータセンター間でやりとりできる、が…
    • VLANタグはつけない
    • サーバ側で先にVTEPを通してしまう
  • 仮想の世界で問題があると、単にミラーポートからDumpするデバッグは難しくなった。
    • Contrail等を使えば楽、らしい。
  • くわしくは
  • 久々に技術的に追いつけない内容だった…

フロントエンドで普及が進むビルドツールたち ? Grunt、gulp ほか

河村 奨 さん

  • 下北沢オープンソースカフェとリブライズの人

  • カフェは東京で二軒目のコワーキングスペースだったそうだ

  • Grunt (ぐらんと)

  • gulp (がるぷ)
    • こちら中心でいきます
  • フロントエンド制作の今
    • デモンストレーション「アンネ・フランク・ライブラリー」
    • 単にHTMLを書くだけでは作れなくなった
    • gulpfile.coffee (coffeescript)
      • 画像ファイルの自動変換
      • いろいろ
      • デザイナが手作業でやっていたものを自動化する (現場にいると本当に大変そうだった)
    • クロスブラウザチェック
      • 同時に複数のブラウザをチェックできる スクロールもsync (めっちゃいいですねこれ)
    • ほぼリアルタイムにブラウザをチェックしながら制作可能
      • HTMLの即時反映
      • 画像のリアルタイム反映もできる (サイズも含めて!!!)
    • それなりに高速に動くらしい
      • 非同期でタスクが走る
      • デモだと 300msec くらいでいける
  • 比較
    • Grant
      • フロントエンド制作の自動化の立役者
      • npmで入れられる デザイナも使うくらいなので簡単である
      • 1年くらい、お世話になったそうです。
    • gulp
      • タスク設定ファイル、Grantと比較すると、1/3くらいの分量。おうふ。
      • コマンド間連携もできます。
      • Googleも乗った。
        • Web Fundamentals – マルチデバイス対応スターターキット タスクランナーにgulp採用
      • 新しめのサイトの制作はgulp採用が増えている
  • gulp
    • package.json, gulpfile.coffee
    • 「ブラウザ直近2バージョンまでサポート」なんてことも
    • インクリメンタルビルド可能
  • 何を自動化するの?
    • LESS, Sass, Styles
    • CSS最適化
      • 「uncss」(使っていないCSSを削れる) – 秘伝のCSSをスリムに
    • CoffeeScript 等のコンパイル
    • Browserify, Require.js, Uglify
      • ライブラリ依存、難読化、圧縮。
    • Style Guide
    • 画像最適化
    • フォント自動生成
  • 何のための自動化?
    • 楽をする。2回同じ事しない。
      • デザイナには鉄則ではなかった。美徳とさえ言われていた事もあった。
    • コンパイル・自動生成
    • テスト・ソースコードの検証
    • リアルタイム化 (LiveReload, BrowserSync)
  • ビルドツールの変遷
    • 石器時代
      • ShellScript, AppleScript, Adobe JavaScript
    • 中世
      • Make – Watchman(Facebook謹製のファイル監視ツール)の影響
      • Rake, Jake, Fabric, Ant
    • 近代
      • Guard, Watcher (ディスコン)
      • Middleman
    • 現代
      • gulp, Grunt, Brunch, Broccoli
    • 平行世界
      • ワークフローが限定的になるので悩ましい
      • CodeKit, Prepros, Atom, …
  • サーバ・クライアント・そして第三極?
    • デザインの現場からの要請
      • ウォータフォール方法論の崩壊
      • レスポンシブ
      • インブラウザ
      • デザインもテストファースト(CI)の時代に
    • 改めて、自動化。
    • 共通プラットフォームとしてnode.jsがデファクト。
    • フロントエンド開発にプログラマが参入した結果が、今。

総務部技術課!? エンジニアのための業務完全自動化へのアプローチ

服部 健太 さん

  • Kompira 開発している所 (2013年のプロシンに来てた所かな?)

  • フォースクーナーはデータホテルに売却

  • 自社プロダクトの紹介。

  • プロシンの発表の後から、どの辺が変わったのだろう。

おわりに

  • 家の用事があって、懇親会には行けませんでした。ちょっと残念。
  • スタッフの皆さん、AIITのみなさん、話者の皆さん、どうもありがとうございました。
  • Mackerel Meetup #1 に行ってきました #mackerelio

    昨夜は、はてなさんが提供を始めたサーバ管理ツール、その名もMackerelに関するお話を伺いに行きました。ITエンジニアの中での俗語ではサーバを「鯖」といいまして、そこからMackerelという名前が来ているようです。

    また、ITインフラ系の方ばかりではなく、プログラマの方等、様々な背景を持った方達の交流の場ともなりました。はてなさんの懐の深さを感じずにはいられません。

    それでは、いつものようにノートをアップしておきます。

    概要

    Mackerelの紹介

    @motemen (おおつぼ)さん

    • 「まかれる」と読む
    • Mackerelディレクターやってます
    • overview
      • サーバ管理ツール as a サービス
      • 元々 社内ツールがあった アイコン「鯖」
      • はてなの知見を活かして、今までとは違うものを提供する事となった。
      • 選択した言語・ミドルウェア、全て新しい試み。
        • Scala + play + postgresql + graphite + angluarjs + go
    • 特徴
      • ロールによるホスト群の管理。
      • エージェントベースのリソース管理。
      • リソースの可視化。
      • APIベースの管理。
    • Orgとユーザ
      • Org単位で課金する予定。
      • ユーザは複数のOrgに所属できる。
    • サービスとロール
      • 様々なホストが強調して動いている…1つのWebサービス単位でまとめる
      • ホスト群を役割でまとめる…ロール
    • ホストのライフサイクル
      • Status: Stdby, Working, Mainte(監視停止)
      • 役割が終わったサーバは「退役」がある
    • Metric
      • Agentが収集→時系列で可視化
      • ロール毎にまとめてチャートを表示できる。
        • (ばらつきとか、問題の有無とかを見つけやすそうですね。)
    • 監視機能が今日からリリース!
      • Alerts メニューだ!!!
      • Agentからしばらく疎通が無いと通知。ホストの死活監視。メールベース。
      • 管理画面から「実験的機能を有効にする」ってのもできた。Experimentalな機能を使いたい場合はこちらです。
      • 今後: 閾値ベースの通知を作りたい。
      • (Web Hook使えるようになるのかな?)
    • APIを公開しているので、Agentは自分で作れまます。
    • yum/apt がオススメ。brew install, go get などもできます。
    • 収集
      • 1分間隔。
      • 今後、1時間位1回収集し直す変更を入れる。
      • 設定ファイルを書き足せばカスタムメトリクスを収集可能。
        • 書式はSensuプラグイン互換
        • 表示方法も編集可能(Webベース)
      • Agent側でRoleの設定を定義可能。無ければ作ってくれる。
        • cookbook-mackerel-agent でも使えます。
    • API
    • CLI: mkr
    • その他のツール
    • はてなさんの事例
      • 有名な某サービスの状態
      • cookbook-mackerel-agent を改良、httpステータスの分布、レスポンスタイムの数値をとる。
        • 見せ方、考えたい。
    • Feedback 歓迎します

    ロードマップ

    田中さん

    • 6月
      • 監視・通知
      • アプリケーションメトリクス
    • 7月
      • グラフ拡充 (カスタム・外部貼付)
    • 8末〜9月
      • 正式化したい
    • 監視・通知
      • 7月に応用的なものをつける
      • 閾値監視
      • 通知手段 (HipChatなど)
    • アプリケーションメトリクス
      • レスポンスタイム・
      • エラーレート
      • サービス全体の状況を俯瞰する
      • カスタマイズ
        • ラベル
        • 形状
      • 監視・通知もつけたい
    • グラフ
      • 外部貼付け
      • 高速化は随時やります!
      • ダッシュボードの使いやすいUIは悩んでいるらしい
    • デプロイ支援
      • デプロイタイミングをプロット
        • (まあ、この辺りで色々起こるもんな。)
      • ロールのバージョニングとgit hashとの紐付け(7,8月)
    • 正式リリース後
      • ユーザ管理権限強化
      • クラウド連携強化
        • LB, インスタンスをキックできたりとか
        • これ欲しいね
      • Docker支援
        • イメージリポジトリ、API操作。
    • カスタムメトリクス関連
      • 色々作っています
      • まとめていきます
      • (Go, Pythonライブラリ欲しいっす)
    • mackerel-client-ruby
    • 連携
      • hubot (ドックフーディング中らしい)

    オススメッ!

    • 簡単セットアップ
      • 複雑過ぎない 簡単過ぎない
    • システム構成要素を一元管理
    • サービスの時系列データを可視化

    質疑応答

    • 事前のご意見・ご要望
      • 台数 (時系列データの管理って大変ですよねー)
        • 2,000台 はてなで実績あり。10,000まではいけるんじゃないか。
      • AutoScale環境で使いやすくしたい
        • ドックフーディング中 がんばって改善しています!
      • サービストップのLoad Avg.を変更できるといい。
        • 検討します。
      • CloudWatchにメトリクスデータを流したい
        • REST APIで今後できるようにします。
      • OSSでの無償提供は考えているか?
        • 前向きに考えます
        • 事例がないので色々相談させて下さい
      • 価格
        • 原則 従量制でいきます
        • ボリュームディスカウントとは考えます
        • 固定が欲しい件は応相談
        • 数値はいずれにしても検討中
    • Web Hook 対応 (質問した)
      • 早い段階でやります。やりたい!
      • アプリケーション間連携の重要性は考えていらっしゃる模様。
    • 代理店 (@netmarkjpさんより)
      • ぜひお話しさせてください
    • メトリクスの細分化 よりリアルタイム化したい
      • あると面白いと思っているが、Agentの実装をどうするか悩んでいる。
      • API的には5秒は受けられない。どうするか考えたい。
      • 需要があるのは確認している。

    おわりに