2019年を振り返ってみる

早いもので、2019年も終わろうとしているので、ちょっと振り返ってみようかと思います。

仕事

大きなこともなく、平穏な1年でした。

データセンターの移行があったり、コンテナ化がだいぶ進んだり、人が増えたり、減ったりしたけれど、管理しているITインフラ自体にはそんなに大きな変化はなかったように思います。

ログ基盤を見直したり、分散トレーシング環境を見直したり、CI環境を見直したり、バッチの方法を見直したり、細かな改善をいくつか行ってはいるものの、そんなことをのんびりやっていたらいつの間にか1年が過ぎようとしています。

Immutable Infrastructure は扱いが良いですね。

会社

色々と変化のある1年でした。

そんなに大きな会社でもなく、事業の進捗などを考えると、良くも悪くもそういうものではないかと思います。

自分の所属するチーム的には、人が増え、人が減り、そしてまた減ろうとしている。といった感じです。

ITインフラというものはそもそも、サービスのスケールとともにスケールしていっていいものでもないので、妥当なのではないかとは思っています。

減るほうが多いのはさすがに厳しい気もしつつ。

ゲーム

iPodAndroid端末で行っているゲームは、1つ入れ替わり、1つ増え、1つあたりに使う時間が減るという1年でした。

成熟したゲームは、時間を奪わず、それでいて今までと同じ結果を出してくれる。みたいな形になっています。

繰り返し作業を効率的にこなせる仕組みが入っているのは、いいのか悪いのか。

使う時間が短くなっても、落とすお金は一緒であることを考えると、良いんだろうなぁと。

これから

来年は、仕事も会社も私生活も、どんな風に変わるのか、まだまだ分かりませんが、自分にとって楽しい年にできるよう、

いったい自分は何を楽しいと思うのか?と問い続けていきたいと思います。

zipkinを移行している話

トレーシングツールとしてzipkinを利用しているのですが、稼働時からサーバのバージョンを上げておらず、クライアント側のバージョンアップでまともに動かない状態になっていたのを更新している話。

今までの構成

構築されたころからのしがらみや人的リソースがないなどの理由から、あまり良い構成とはなっておらず、下記のような状態でした。

f:id:paihu:20191106213636p:plain
Before

データセンター側にzipkinサーバがあり、ストレージとして、AWSのElasticsearchServiceを利用しています。

トレーシング情報を送信するアプリケーションサーバAWS上にあり、わざわざデータセンターまでトレーシング情報を送信していました。

移行後の構成

流石にまずいと、構成含め、色々話をして下記のような構成に移しました。

f:id:paihu:20191106214246p:plain
After

全てがAWS上にあり、完結しています。

雑感

構築する上で特に大きく躓いた箇所はないけれど、アプリケーションには、zipkinライブラリが組み込まれており、zipkin v1のトレーシング情報を送ってくるものと、v2のトレーシング情報を送ってくるものが混じっていたこともあり、送信側を修正するのは大掛かりになりすぎるため、行わないという判断をしています。

また、今のところzipkinを引き続き利用しているけれど、AWS X-Rayや、Jaeger、その他、マネージドサービスに置き換えたいという話もあり、拡張性を見越して opentelemetry collector を アプリケーションとzipkinサーバの間に挟んでいます。これにより、将来、移行したい場合は、opentelemetry collectorの設定変更などで対応ができるようになっています。

今後、使いやすい分散トレーシングサービスが出てきても、opentelemetry に対応してさえくれれば、おそらく、構成を大きく変えることなく、使い続けられるだろうと思っているので、満足度の高い構成変更になったと思っています。

gitlab-runner トラブルメモ

Gitlabを利用しており、CIにgitlab-runnerを使っていてであったトラブルについて

AWS上でdocker+machine構成

確率でジョブが失敗する

ubuntu 16.04 18.04にて、特定のジョブが確率で失敗するというもの

CIの中でtest serverを起動して ローカルで待ち受け、そこに接続するタイプで、接続がうまくいかないというもの。

centos7 にしたところ起きなくなった。結局根本的な原因は不明。

dockerのバージョンやkernelのバージョンが影響したのかもしれないと考えている。

中央リポジトリへデータを取得しに行く際403が出るようになる

これは単純で、中央リポジトリへデータを取得しにいくジョブが並列で大量に動いたため、(同一グローバルIPアドレスを共用していた) 中央リポジトリサーバからabuseされていた。

内部に中央リポジトリサーバのキャッシュを置くことで対処した。 (グローバルIPアドレスを共用しない方法も考えられるが、行儀が悪い気がしたのでその方法はとらなかった)

alpine を利用している node などでエラーにより失敗する

docker+machineで利用するVMAWSのm5シリーズにしたところエラーが出るようになった。

Error with Node:8-alpine docker image on AWS using an M5 instance type · Issue #813 · nodejs/docker-node · GitHub

m4シリーズにすることで解決(?)。

他も何かかけそうなのがあったら追加していく。