可用性の高いcron処理の為にJob Observerパターンを使う

1日に一度だけ、1時間に一度だけ、あるタイミングで処理を走らせたいというニーズは常に存在します。昔から多くのエンジニアはそういった要望に対して、サーバを用意して、crontabに独自の魔法を書くことで対応していました。

時は現代、インフラといえばAWS、GCP、Azure... サーバを使い捨て可能なリソースとして扱えることのメリットに人々は熱狂しました。また、AWSが掲げた思想、"Design for Failure"（障害の為の設計）は多くのエンジニアに受け入れられました。
ここで改めて定刻に処理を行う方法について見てみると、やっぱりインスタンスを立ててcrontabを利用する方法が使われているようです。これは決して可用性の高い実装ではありません。なんとかしなくてはいけません。

以前、同様の問題に対して、DataPipelineを用いたアプローチを検討しましたが、スケジュール処理をDataPipelineに委任しているだけで、可用性が高いとはいまいち言えませんでした。

そこで今回は、CDPでも紹介されている可用性の高いバッチ処理のデザインパターン、Job Observerパターンを使って、可用性の高いcron処理基盤を構築してみようと思います。

PackerとTerraformで始めるミニマムなAWS構成管理

前回の記事ではDockerとECSを使ったAWS上でのInfrastructure as codeについて言及しましたが、サーバリソースの構成管理についてはAWSのマネージメントコンソールから手動で行わないといけなかったり、コンテナを用いたアプリケーション構成を強制され、従来の単純なインスタンス構成ができないという問題点がありました。前回の記事はこちら。

後者については、今後コンテナを活用したインフラ構成が普通になっていくことで許容されていくかもしれませんが、普通にインスタンスを立ててインフラを構築している方にとってはInfrastructure as codeをやりたいためにコンテナを前提としたサーバ構成に変更しなくてはいけないなんて、正直気が進まないと思います。

そこで本記事では、今インフラ界隈で非常に強い影響力を持っているHashicorpのプロダクト、PackerとTerraformを使って従来通りのインスタンス構成でInfrastructure as codeとAWSの構成管理を小さく始めてみようと思います。

DockerとECSでInfrastructure as codeを体感する

Infrastructure as codeの思想に感動し、AWSを使い始めて早1年になりますが、なんだかんだで最近はコードを書いてばかりでAWSを触っていませんでした。貴重な無料期間も終了し、非常にもったいないことをしたなと反省中です。

さて気を取り直して、ついに先日 EC2 Container Registry (ECR)がアナウンスされましたね！

まだUSリージョンのみの公開で、相変わらず東京リージョンはもう少しかかりそうですが、これでDockerイメージの管理までAWS上で行えるようになるわけです。

ところで、インフラ構築の自動化といえば、Elastic BeanstalkやOpsWorks、CloudFormationなどなどAWS上でもサービスが乱立しており、少し外に目を向ければ、Chef、Puppet、Ansible、Terraformなどなど、もう困っちゃうぐらい選択肢にあふれている昨今です。
ただ、どうにもこれらの選択肢はアプリケーションのデプロイに難があったり、やたらと複雑だったりでイマイチピンと来ない部分があって、インフラのコード化という視点から見るとDockerが一番しっくり来る感じでしたので、今回はECRの東京リージョン公開を期待しつつ、ECSでInfrastructure as code的なものをやってみたいと思います。

FuelPHPのデフォルトバリデーションルールの仕様について調べた話

最近仕事でFuelPHPを使う機会を得たのですが、FuelPHPのデフォルトで用意されているバリデーションルールで少しハマった部分があったため、戒めのためにまとめておきます。

意外とググッても情報が出てこない部分があって、公式ドキュメントはそれなりに充実しているものの、細かな仕様までは書かれていません。最終的にはコアのコードを読むのが一番だと気づいてようやくバリデーションルールの仕様がわかってきたのですが、やっぱり困ったらコアのコードを読む気持ちを持とうよという話です。

Railsで好き嫌い管理アプリ作った

https://kobayasitabel.herokuapp.com/

タイトルの通りです。
知人の好き嫌いが激しすぎて何ならば食べられて何ならば食べられないのか判別が難しかったので勢いで作りました。
中身は大したことのない簡単なものですが、Railsの開発の速さと生産性の高さを感じることができたのはいい経験でしたね。

ローカルで開発したRailsアプリをCapistrano3でEC2にデプロイする

最近RailsのScaffoldから色々開発するのにハマっていて、WEBRickで動作確認しながら、ちょこちょこ開発していました。
そろそろ公開環境へのデプロイ自動化を考えないとなーとなって、せっかくなので今までやっていた単純なAnsibleを使用した形ではなく、デプロイ支援ツールであるCapistranoを使ってローカルマシンからデプロイする手順を自動化してみました。
ちなみに、今までまとめてきたAnsibleを使った形式は以下の記事にあります。

RailsのScaffoldでネストしたResourceを作る

先週、Rails寺子屋に参加させていただきまして、いまさらながらRailsデビューを果たしました。もともとバックエンドにはFuelPHPを使っていたので、未だにRuby独自の記法に四苦八苦しながらも、Scaffoldの強力さに感動を覚えている次第です。お恥ずかしながら、FuelPHP使っていたときにはmigrationとか使うことはありませんでした・・・

Railsを触り始めて「とりあえず頭の中にある作りたいものを、最小構成で作ってみよう」と思いたち、複数のグループがあって、そのグループに属するユーザが複数いて・・・みたいなのを作り始めました。しかし、Resourceをネストさせる辺りで詰まったのでメモ。