ホイールをCampagnolo Zondaに変更した
今年の夏もあんまり走りに行けなくて後悔してます。 走りに行けなかった悲しさをカスタマイズで埋め合わせるという毎度のパターン。
というわけで、ホイールを新しくしました。
選ぶ
以前使ってたのはMiche Reflex RX5というイタリアのコンポメーカーのホイール。 完成車に元から付いてました。
フロント945g, リア1,175gの計2,120gという重量からして立派な鉄下駄です。
で、買ったのはご存知Campagnolo Zondaのクリンチャーモデル。
フロント660g, リア880gの計1,550gなので570gの軽量化!
以前の会社の先輩から「ホイール買うならFulcrum Racing 3以上のグレードがいい」と聞いていたので単純にRacing 3を買おうかと思っていたんですが、 カンパ乗りはカンパでいいんじゃね…? となったのでRacing 3相当(だと思われる)のZondaにした、という経緯です。
Zondaより上のグレードのホイールであるEurusも検討しました。 ZondaとEurusの違いとしては
- ZondaはステンレススポークだがEurusはアルミ
- ZondaはアルミのハブボディだがEurusはカーボン
- Eurus以上のグレードにはホイールバッグが付属
といった感じ。これでZondaから100g程度の軽量になっているんですが、価格が倍近いのでホビーライダーにはちょっと厳しい。
届く
購入はいつも通りWiggle。CRCやEvans Cyclesなどと価格を比較して一番安かったです。 配送に10営業日かかる無料配送プランにしたんですが、6日で届きました。 関税は通関料込みで2,100円。
梱包はこんな感じ。
付属品。
内容は
の4種類。カンパフリーハブモデルなので、10s用スペーサーは入ってません。
公式ページにある通り、付属するクイックリリースはグレードによって異なり、Zondaに付属するものは下から2番目で120g。 2015年モデル(pdf)においてはShamal Mille用クイックリリースが増えたので全5種類あります。
Zondaを箱から取り出したところ。
ちょっと暗くてわかりにくいですが、クイックリリースをつけるところにはカバーが付いていてダンボールを突き破らないように保護されています。
またハブのところにはCampagnolo Identification Card: C.I.Cなるものがついていて、ホイールビルダーの署名とともに振れやスポークテンションなどがチェックされています。
ちゃんとチェックされているおかげなのか、「カンパのホイールは振れている」というよく聞く評判に反して振れは見つかりませんでした。
付ける
スプロケットの交換は工具を持っていないので近所の自転車屋さんにやってもらいました。 持ち込みかどうかによっても違うため一概に言えませんが、調べた限りでは工賃は800円〜2,000円が相場。
持ち込んだときにお店の人がシマノハブだと勘違いして「スペーサーないの?」と言われて焦りました。 前述の通りカンパは10sと11sともに互換性がある高さのためスペーサーが付属しないのですが、今回調べるまでそれを知りませんでした(おい)。
タイヤも履かせてフレームにつけた状態がこちら。
黒スポークとスポーク本数が減った影響か結構すっきりした印象に。イケメン!
乗る
とりあえず試走のために皇居周辺を30kmくらい走ってきた印象です。
- 持ち上げた時の感覚が圧倒的に軽い
- 走り出しがスムーズ。信号待ちが多くても疲れにくそう
- 力がダイレクトに伝わる感じがする
- 路面の振動が以前よりダイレクトに来る
- 緩い傾斜は坂だと感じなくなった
- 普通の坂は多少楽にはなっているけど、思ったよりつらさはあんまり変わってない
- やっぱりラチェットが爆音
巡行スピードが上がったとか数値的な結果が出せていないので、これからが楽しみです。
elastic beanstalkをimmutableに運用する
AWSのelastic beanstalkはURLスワップ機能やauto scalingによるインスタンス増減機能があるため、immutable infrastructureやblue-green deploymentの文脈で語られることが多いかと思いますが、実際に運用しようとすると考えなければいけないことがたくさんあります。
ちょうど今elastic beanstalkの運用を行なっていて安定してきたので、elastic beanstalkでimmutable infrastructureに運用するためにはどうすればいいのか?というのをまとめてみます。
目的
- elastic beanstalkの環境構築とデプロイを自動化し、immutableに運用できる環境を作る
デプロイ
デプロイする方法はいくつかありますが、今回はeb
コマンドを利用します。
ebコマンドを使う理由は以下の通り。
- 操作が簡単
- gitのリポジトリが簡単にデプロイできる
optionsettings
やebextensions
を利用すれば設定をコードとして管理できる
通常は対話式で入力していくことになるのですが、以下のような適当なシェススクリプトを作成するだけでコマンドによる自動化も簡単です。
GIT_BRANCH='master' ENV_NAME=`date +"%Y%m%d-%H%M%S"` # parse opts while getopts b:e:r: OPT do case $OPT in b) GIT_BRANCH=$OPTARG ;; e) ENV_NAME=$OPTARG ;; esac done # checkout git checkout ${GIT_BRANCH} git pull origin ${GIT_BRANCH} # create new eb environment expect -c " spawn eb branch expect \"Enter an AWS Elastic Beanstalk environment name (auto-generated value is *):\" { send \"${ENV_NAME}\n\" } expect \"Do you want to copy the settings from environment * for the new branch?\" { send \"y\n\" } expect \"Would you like to deploy the latest Git commit to your environment?\" { send \"y\n\" } " # deploy to aws eb start && git aws.push --environment ${ENV_NAME} # clean up git reset --hard HEAD git clean -f
以下、eb
コマンドでのデプロイを前提に進めます。
URL
ebコマンドでenvironmentを作成すると、デフォルトで<environment名>-<ハッシュ>.elasticbeanstalk.com
というURLがそれぞれのenvironmentに付与されます。
独自ドメインで運用する場合はこのURLに向けてCNAMEを張って、environmentのswapで切り替えていくことになるので、公開中のenvironmentであることがわかる名前がいいと思います。ちなみに自分の環境では本番用URLが割り当てられるenvironment名はproduction
としてあります。
(ちなみにルートドメインの場合はCNAMEを張れません。Route53の場合も同様で、AレコードのエイリアスにELBを設定するためURLは関係なくなります。)
また、公開中のURLに紐付かないenvironmentは継続的デプロイで自動作成してステージング相当の環境として利用すると思うので、
- 機械的に採番できる
- 推測しにくい
- URLスワップしても意味がわかる
environment名が望ましいと思います。自分の環境では上のデプロイスクリプトにあるようにyyyymmdd-hhmiss
というenvironment名をデフォルトにしてます。
プロビジョニング
基本はoptionsettingsやebextensionsを利用してenvironmentやインスタンスの作成時に設定などを行う運用になると思います。
- optionsettings
- ebextensions
またこれらのファイルはeb init
によって.gitignore
に追加されているのですが、gitの管理下に置くことで設定やリソースなどをコードとして管理することができます。
しかし、もともと遅いelastic beanstalkのセットアップに加えて追加のパッケージのインストールなどを都度行っているとさらに時間がかかってしまうため、Auto Scalingで頻繁にインスタンスが増加する場合には設定済みのAMI用意する必要が出てくると思います。
ちなみに自分の環境ではchef+berkshelf+packerでAMI作成を自動化していますが、少し前にelastic beanstalkがdockerコンテナに対応したので、dockerを使うのもアリだと思います。
DB
当たり前の話ですが、immutableに運用するためにはDBは外出ししなければいけません。
RDSを利用する場合、optionsettingsで紐付たりebextensionsから作成を行ってしまうとenvironment削除時にRDSのインスタンスも削除されてしまうので、作成は別に行う必要があります。
通知/監視
SNSを利用する場合は、optionsettingsのaws:elasticbeanstalk:sns:topics
で指定したトピックやebextensionsのType: AWS::SNS::Topic
で作成したトピックは環境削除時に削除されてしまいます。
またSNSは、メール通知するアドレスの確認作業がトピック作成を行うたびに必要となってしまいます(メール以外の通知方法に関しては未調査)。
なのでメールアドレスの確認作業が自動化できない場合は、SNSのトピック作成をあらかじめ行うようにして、optionsettingsのaws:elasticbeanstalk:sns:topics
には指定しないようにしましょう。
CloudWatchを利用する場合は、(environment削除時にひもづいているアラームも一緒に削除されてしまうため)ebextensionsのType: AWS::CloudWatch::Alarm
でenvironment毎に作成する必要があります。
アラームが削除されると計測した値も削除されてしまうので、継続的に計測したい場合は別途監視サーバが必要です。
ちなみにType: AWS::CloudWatch::Alarm
のAlarmActions
やInsufficientDataActions
に指定したSNSトピックはenvironment削除時に削除されないので、CloudWatchのアラームはSNSを通して通知可能です。
CloudWatchのAlarm作成は以下が参考になります。
- https://github.com/lapygithub/eb_config_examples
- http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CW_Support_For_AWS.html
ログ
.elasticbeanstalk/optionsettings
にあるLogPublicationControl
をオンにすることでアプリケーションやWebサーバのログを自動的にS3にアップロードしてくれます。
しかしS3に保存されるログファイルのパスは${environment-id}/${ホスト名}/${ログファイルのパス}.log-${YYYYMMDD}.gz
となっていてenvironmentやホストをたくさん作って捨てる運用方法だと参照がしにくいので、自分の環境ではfluentd(tdagent)を利用しています。
fluentdを利用する場合はauto scalingによってインスタンスが突然死する場合に備えてflush_at_shutdown
とか設定しておくといい感じです。
まとめ
上に挙げた通りenvironmentの削除時に消えてしまうリソースがあるため、そこだけ気をつけていれば基本的には問題ないと思います。 みんなでimmutable infrastructureなelastic beanstalkを満喫しましょう!
なつまちスタンプラリーと木崎湖に行ってきた
もう2週間も前になりますが、5/10, 11の土日で長野に行ってきました。 目的は小諸で行われたなつまちスタンプラリーへの参加と、木崎湖に行くPlase!の聖地巡礼です。
とても良い旅行になったので、振り返ってみようと思います。
準備編
以前ツールド東北に参加したときはカンガルー自転車イベント便を利用したんですが、今回は友達から輪行袋を借りて輪行して行きました。初輪行。
コクーン ポーチタイプ COCOON POUCH-BK タイオガ TIOGA 輪行袋 BAR02800
- 出版社/メーカー: タイオガ
- メディア: その他
- 購入: 7人 クリック: 149回
- この商品を含むブログを見る
この前輪だけ外すタイプだったんですが、かさばるし持ちにくくて疲れた!友達からは前後輪外すタイプをオススメされたので、自分で買う時はそっちを選ぼうと思います。
あと、5月上旬とはいえ長野は結構肌寒かった!上着を持って行けば良かったと若干後悔してます。
なつまちスタンプラリー
出発は5/10の朝から、上野から軽井沢まで長野新幹線で行き、軽井沢からしなの鉄道で小諸まで行きました。
コースはロングコースを選択。ロングコースと言いつつも距離はたいしたことありませんが、結構高低差があるので坂と景色を満喫できます!
ツールド東北と同様、今回もコースを把握してないせいでペース配分がわからず、中盤の坂(斜度7%で3.3km!)でだいぶ暗い気持ちになりました…。が、上りきったところにある御牧大池はとても眺めがよかったです!
こちらは斜度6%の下り3kmを越え、県道139号線の先にある乙女湖公園。機材トラブルで最後尾を走っていたため、ここで回収車の方から小諸の話をいろいろと伺えました。
今回は走るペース配分ができなかったのも良くなかったんですが、それ以上に機材トラブルが多くて反省です。 初めての輪行ということもあり組み立て時には入念に確認をしたつもりなんですが、ブレーキのセンタリングがずれたり、走ってる途中で後輪のクイックがずれたりと危険な状態でした。 なんとか怪我なく完走できてよかったのですが、次からは万全に走れるよう気をつけようと思います。
この日は宿が松本だったので、早々に小諸を離脱しました。次行くときはちゃんと予習して、珈琲こもろ以外も満喫したいです!
木崎湖
2日目の朝は松本のホテルに自転車を預けて、旧制松本高等学校の観光。 昔見てた木崎高校そのままで、一緒に行った友達とテンションマックスでした。
その後は松本城をスルーして、木崎湖に行くため松本駅からJR大糸線に乗って信濃大町まで。大糸線はSuicaやPasmoが使えないので注意。信濃大町で降りたのは木崎湖の目の前に行く電車の待ち時間がかなり長いので、信濃大町のロッカーに荷物を預けて木崎湖に行きました。
木崎湖周辺は本当にどこかで見た風景ばかりで、どこ走ってても楽しかったです! その中でも一番テンションが上がったのは、やっぱりみずほ桟橋。
その他も、小諸で買っておいた聖地巡礼本のおかげで取りこぼし無く巡礼を満喫できました。 ただ心残りなのは、この日もあまり時間がなかったこと。16時くらいには切り上げで、松本からスーパーあずさで帰ってきました。
感想
大部分が移動時間や待ち時間だったのであまり観光に時間が割けなかったのですが、それ以上に充実感の高い旅行になったと思っています。 今回行ったことで小諸や木崎湖の距離感がわかったので、次は余裕のある旅行にしたいと思います。
皆様もぜひ!