本記事は
【Advent Calendar 2023】
5日目の記事です。
🎄
4日目
▶▶ 本記事 ▶▶
6日目
🎅
今回はクラウド活用をしていく上でアプリケーションチームとインフラチームとの間でどのようなコミュニケーションを取っていくべきかをまとめてみようと思います。 また、インフラエンジニアとして僕が普段アプリケーションチームの方と接する時に意識していることも併せて整理してみました。
アプリとインフラどっちがやるんだ問題
いきなりですが、このような構成のAWSシステムがあるとします。ECSをベースとしたアプリケーションでGitHub Actionsを利用してCI/CDパイプラインも構築します。随分とモダンな設計ですね。
サービスアーキテクチャの一例
ここで問題になってくるのが、オレンジ枠の部分です。ここをアプリとインフラ果たしてどっちが設計・開発・管理するのか。 ワークフローはアプリをデプロイするという観点では、アプリのリポジトリで実行することになります。とはいえ、実際のCI/CDを組むことになると、ECRやCodeDeployなどのAWSインフラ周りが絡んでくる可能性もあります。したがって、必ずしもアプリで管理するからと言って、アプリチームの独力でできるとは限りません。
担当者が不明確になりやすい領域
ECS上でDockerコンテナを稼働させる場合も同じことが言えます。ローカル上で動いていた物をそのままECSに乗せても稼働しないことは往々にしてあります。そうなってくると、アプリチームの独力で解決するというのはやはり現実的ではありません。両者がそのまま開発を進めていくと、いずれこういった問題に直面します。これってどっちがやるべきなの？という状態です。
ポテンヒットとは
ブログのタイトルにもあるポテンヒットとは本来、野球で使われる言葉です。内野と外野の間にフライが上がって、それを誰が捕るのか、あたふたしてる間に地面に落ちてしまい、結果としてヒットになることを言います。転じて、ビジネス界隈では「あ、そっちがやると思ってた。。」状態を指します。先述のECSのようなアプリとインフラが密に関わる領域ではポテンヒットが生じやすい傾向にあります。
ポテンヒットのイメージ
エンジニアの境界はより曖昧に
僕はキャリア的にずっとインフラエンジニアをやっているのですが、最初の数年間はオンプレを触っていました。当時はインフラエンジニアと一口に言っても、ネットワークエンジニアやサーバエンジニア、サーバーエンジニアでもDB担当など、物理的に分かれている状態なので細かい役割が存在していました。
しかし、今はどうでしょうか？AWSの様なクラウドプロバイダーを利用していれば、物理レイヤーは完全にクラウドプロバイダー側で管理されます。マネジメントコンソールからワンクリックしてしまえば、サーバ、DB、ネットワーク構築も簡単に行えます。経験上、サーバエンジニアとしてオンプレ時代を過ごした身からするとNWの知識はそこまで無くても困らなかったのですが、クラウドを触ってるとそうも言ってられません。技術の進歩によってこういったエンジニアの垣根がなくなってきているように見えます。つまり、それは逆に言うとエンジニアとしてはより幅広い知識が求められているという見方もできます。
オンプレとクラウドを比較した際のインフラエンジニアの変化イメージ
更に昨今では、アプリとインフラの境界ですら曖昧になってきています。それは先述のECSの例を見ていただければお分かりいただけるかと思います。ここからここまではインフラ、こっから先はアプリと言ったように明確に区分するのが難しくなってきてると言えますね。
様々なサービスの出現でインフラとアプリの垣根も無くなりつつある
重要なマインドセット
こういった背景を踏まえてどのようなマインドセットが必要になってくるのか？というと以下の２つが重要です。
ポテンヒットは起きるという事実をまず知ること
こういった事象は起きるものなんだと事前に知っておくことが大事です。僕もクラウドを利用する案件で、アプリケーションチームの方とコミュニケーションを取る機会があるのですが、オンプレ時代とは違うなと感じることが多いです。しかし、ポテンヒットが起きやすいんだなという前提理解があると、事前に対策を取ることが可能です。
アレルギー反応を起こさない
アプリ分からない！インフラ分からん！などとアレルギー反応を起こさないことが重要です。クラウド時代において両者がお互いの領域を理解するのは今後必須課題になりつつあります。オンプレ時代はそれでも問題なかったかもしれませんが、クラウド時代においてアレルギー反応を起こすことは事故の引金となります。関係ないと思わないことが非常に重要です。
密なコミュニケーションを取る
具体的にどんなコミュニケーションが必要なのか？については以下の３つが重要になります。
1．全体像を共有する
冒頭のECSの構成図のように両者で全体像を共有することが大事です。その上で、じゃあどうやって各タスクを消化していくかという議論に繋がっていくかと思います。
全体像をベースにした役割分担のイメージ
2．前提知識に違いがあることを理解する
例えば、マイグレーションと聞いた際にどんなイメージを持たれるでしょうか？インフラエンジニア歴が長い僕からすると、オンプレからクラウドに移行するマイグレーションのことかな？と思います。
一方で、Ruby on Railsの世界ではマイグレーションとは、データベースの構造を変更する際に利用される機能です。このようにアプリとインフラチーム間では、同じ言葉でも定義が異なる場合が往々にしてあります。ですから、同じエンジニアでも前提知識に差異があることを理解し、言葉の定義についても都度、確認することが重要になります。また、両者がお互いの領域について深い見識を得るのは一朝一夕にはいきません。え？そんなことも知らないの？という考えを持たずに両者を尊重することが大事ですね。
同じ言葉でも解釈が異なる場合がある
3．課題を共有する
お互いの課題やテストの進捗状況などは密に連携を取りつつ開示していくことが重要です。アプリに影響がないと思っていたら実はあったり、または逆も然りです。発覚した課題や検討事項を共有・相談することが事故防止になります。
課題やスケジュールの共有が重要
さいごに
今回ECSを例に出してみましたが、こっちはインフラがやってこっちはアプリがやるべきだ！！という正解はありません。それは両者の関係性やスキルセットに依存するからです。そういった様々な要素を加味しつつ、どうやってポテンヒットを防いでいくべきなのかを模索することが重要かなと思います。
また、クラウドのメリットは、リソースを簡単に作成して、簡単に破棄できる点です。ですから、先ずは動いてみるfail fastをモットーに色々と試してみることも重要です。ぜひ一人でも多くの方に参考になると嬉しいです。
