はじめに
みなさまこんにちは。なんとか生き延びております、たかのです。
いきなり本題ですが、事業を長く続けていると、サービスの中核のシステムは肥大化します。 複雑さが増せば、理解も運用も大変になってきます。
そんな複雑さを回避するために、小さい単位で機能を分割し、別システムに切り出すことはよくあることです。 クラウドワークスにも、中核のシステムを支える小さなシステムがたくさんあります。
生きているからこそ、お世話がつづくのです
システムは生き物です。（そうは思えないかもしれませんが、そんなものと思ってみてください！*1）
稼働はしていても拡張や整理の判断ができず、「属人化」どころかその進化系で、作った人が退職して詳しい人が誰もいなくなってしまったもの。 そんな状態を、わたしたちの職場では「無人化」と呼んでいたりします。
こうした状況は望ましくないので、メンテナンスを仕組み化し、チームで分担して取り組むようにしています。
さて、わたしたちのチームも、この「無人化」対応のタスクを1つ担当することとなりました。 その際のあれこれや学びについて、わたしの「 余技 」をふまえてお伝えします。
- はじめに
- 無人化システムをひきうけるよ！！
- まずは読み解こう！
- あれれ？検証環境で動かない！？
- いよいよ本番も入れかえ！
- 継続メンテは可能？まずやってみよう！
- インフラも学んでいこう！
- やってみての学び
- まとめ
- We're hiring!
無人化システムをひきうけるよ！！
まずは読み解こう！
あれれ？検証環境で動かない！？
いよいよ本番も入れかえ！
継続メンテは可能？まずやってみよう！
インフラも学んでいこう！
※この顛末についての補足
Rails6のNotable Changeに、DNSリバインディング攻撃への対策が追加されています。
なお、In other environments Rails.application.config.hosts is empty and no Host header checks will be done. と書かれています。config.hostsが空なら、このチェック自体は行われません。
ただ、このマイクロサービスは、外部からのコールバックを受け取ったり、外形監視を追加しています。
できればこの対策は有効にしつつ、ALBからのヘルスチェックも通したい。
上記の例ではNginxが前に立っていたので、ヘルスチェック用のホストヘッダを追加し、Rails側のホワイトリストにも、そのホストヘッダを追加ということでいったん回避しました。
Nginx側でヘッダを追加させなくても、ALBからのリクエストがどのアドレス、どのネットワークに対してのものなのかがわかれば、IPアドレスでの指定が可能です。ただ、インフラの構成が変わる可能性があり、アプリケーション側では関与仕切れないため、この対応で乗り切りました。
やってみての学び
将来のだれか、もしくは自分がこまらないために
無人化してしまった場合は残念ですが、そうでなくても、人は忘れます。 なぜその時この仕組みを採用したのか、なぜこんな設定が入っているのか。
記録が少しでも残っていると、圧倒的に作業がしやすくなります。 コミットログでも、Wikiでも、プルリクエストでもなんでも構いません。
作業を通しての「なぜこの設定なの？」が多くありました。 同じく、わたしたちもまた、「なぜこんなことをしたの？」と将来思われるであろう設定も追加しています。 だからこそ、「うーん、これは書いておかないといけないな」ということを実感しました。
たぶんこうした記録は、「入れ替え」よりも「存続するかどうか」の判断に迫られた時に、非常に役に立つはずです。
こちらに関連して、わたしの好きな本の一章を添えておきます。
xn--97-273ae6a4irb6e2h2ia0cn0g4a2txf4ah5wo4af612j.com
まとめ
以上、「どんなことをするのか」「なぜやるのか」を、少しでもお伝えできれば幸いです。
「新築物件」も、一度でも入居されれば「中古」になります。システムも、一度そこで動かし初めてしまったからには、維持を考えなくてはなりません。 場合によっては、今回のようにインフラも含めて面倒をみることもあります。 「大丈夫そうかな？」と思っても、動かし続けながら、トラブルなく切り替えるためには慎重さが必要です。
ただ、「ああ、厄介だなあ」と思っても、食わず嫌いで手を出さないのはちょっともったいない気がします。 「一応は手をつけなくても稼働が担保されているシステム」ですし、SREのみなさん、愉快なエンジニアのみなさんがいるので、「困ったら泣きつこう！」と思える心理的安全性もあります。
また、チームとして取り組む際には、チームでの意思決定も考慮してもらえます。
- 本当にこのシステムは必要なんだろうか
- 当時は解決方法がこれしかなかったけれど、今なら置き換えできるかも
- もしかしたら、機能そのものが要らないかも
- コストとの見合いで、外部サービスにしてもいいかも
担当システムを維持するのが唯一の解ではないので、段階的にチャレンジを含めることも可能です。 維持する場合であっても、「今回はこれを覚えよう」といった目標を1つでも持つと、作業はまったく違うものになって来ます。
どうせやるなら楽しんで。
「 おのれALB....！！いつか必ずネタにしてやる！！！ 」と思いながら対応していましたので、やっと終わってこうやってチームの記録として描けたことは何よりでした。*2*3
We're hiring!
クラウドワークス では、働き方の変革に挑戦するエンジニアを募集しています！ 個性豊かで、愉快なエンジニアがお待ちしています。まずは気軽にお話してみませんか？
