はじめに

複雑な仕組みは例外に弱く、シンプルなインフラのほうがいいよね！って常々思うわけです。
ある日ふと思いました。
シンプルって何だろう。
自分の考えを自分に残すためのメモ。

シンプルについてググってみた

weblio英和辞典様によると

　簡単な、やさしい、簡単で、やさしくて、単純な、込み入ってない、基本的な、簡素な、凝ってない、地味な

なるほどなるほど。

開発では

インフラ界隈でもシンプルにしようという動きはあると思いますが、開発界隈のシンプルさに学ぶところが多いと思っていますので、開発界隈で個人的にシンプルだなーと思う考え方を挙げます。

• マイクロサービスアーキテクチャ
• クリーンアーキテクチャ
• CI
• CD

…なんだか挙げたらキリがなさそうですが、根っこをたどるとオブジェクト指向に行き着くような気がしました。

インフラはオブジェクト指向だよね

インフラってオブジェクト指向だよね、って私は思うわけですが、インフラ界隈のメンバー的にはどうなんでしょう。
私が持っているオブジェクト指向のイメージとしては責任を持つ担当者が責任を果たすと考えています。

インフラに当てはめると…

• ネットワークはパケットを元から先に届ける責任を果たす
• Webサーバーはブラウザからのリクエストを受け付け、レスポンスを返す責任を果たす
• アプリケーションはWebサーバーから受け付けたリクエストを解釈・加工し、レスポンスを生成する責任を果たす
• DBサーバーはアプリケーションからのリクエストに応じてデータを抽出、保存、削除する責任を果たす

他にもCDNや認証、バックアップなどなど役割が明確なものが多く、責任範囲を明確化し、その責任を果たすことが出来るプロダクト群がそろっている気がします。

インフラはシンプルだ？

そもそも〇〇サーバーって名前が付くぐらいなんだから、その名前付けによって責任範囲は明確だし、各種サーバーで構成されるインフラはシンプルなんだ！！

残念ながら、ちがう！

〇〇サーバーは一つじゃない

いろんな事情から、同じ役割を持つサーバーが複数存在します。
例えばDBサーバー。

• アプリケーションの親和性や目的により使用するDB基盤が異なる
• セキュリティの観点から、他アプリケーションとDBを共有できない
• 各種寿命の観点からDBを共有できない(このDBにつないでもEOLがあと1年だからーみたいなやつ)

パッと思いつくだけで3つもあるんで、まだまだありそうです。

お前は何なんだよ！

過去のプロジェクトでこんなサーバーを見てきましたよ。
って今も見るやつがあるか…。

• 共通機能サーバー
• 連携サーバー
• ツールサーバー

共通機能ってなんだよ！って思っちゃいますけど、共通の機能をコンポーネント化してあるっていう意味では有り寄りの無し？
お前にはきっともっと適切な名前がある！んだろうけど、日本語で適切な名前を付けようとすると長くなるし、ホスト名でいい感じの名前つけたいしっていう大人の事情を理解してくれよ！

連携サーバーもそう。
連携ってなんだよ、何と何を連携すんだよ！って思いますけど、こちらも似たような事情でしょう。

世の中にはわざわざ個別に建てるまでもない便利屋さんサーバーが必要なんです。
ツールサーバーなんて私も作った気がします。ごめんなさい。これからも作ると思います。だって便利なんだもん

私の考えるインフラに求めるシンプルさ

シンプルさって何だろう。
自分なりに挙げてみます。

• 小さい
• 少ない
• 狭い

小さいインフラ

先ほどのように各種プロジェクトごとにWebサーバーなどが乱立してしまうのは仕方がないと考えましょう。
古い体質の残っているインフラ界隈だと、Webサーバーを複数のプロジェクトで共有して構築のコストを下げよう！みたいな発想がいまだに残っているかもしれませんが、事故の温床でしかありません。
各プロジェクト単位でインフラをパッケージングするイメージでWebとDBのセット、というような小さいインフラを目指したほうが良いと思います。
すべてクラウドだったとしても、クラウド上でセットを作って小さいインフラを維持したいです。
クラウドでさくっとサーバー作れるんだし、パッケージの塊でシステムを構成しましょう！
開発環境作るときにも便利だと思います！

少ないインフラ

サービスを提供するコンポーネント数が少ないほうが障害が少なくなるのは当たり前の話。
3層アーキテクチャはもう廃れて、キャッシュやAPIのルーティングなどが当たり前になってきているのかもしれませんが、パッケージ化してセットにするイメージでインフラを構築すればCDNとWebはもうセットだから1つっていう暴論も有りだと思います。
大切なのは場当たり的な対応、その場しのぎの対応で余計な構成要素を増やさないこと。
これが大事だと思います。
過去にやったことがあります。

狭いインフラ

影響範囲が狭いインフラ。
〇〇っていう作業をやるときにだいたい現れる影響範囲ガチ勢。
「影響範囲が読めないので作業は許可できません！」
影響範囲が広いインフラをまず疑いましょう。
想定外の影響が万が一発生したとしても、範囲を狭められるようなインフラを目指しましょう。
これはそれぞれの考え方の問題でもあるので強制はできませんが、私は不確実性に挑戦できる未来に居たいです。

最後に

これらが達成されたインフラは障害が起きにくく、障害箇所の特定がしやすく、リカバリも容易で、把握も容易なインフラになるでしょう！たぶん！

全部個人的な見解です。異論は認めます！