クラウド時代にアプリチーム／インフラチームを分けて考えるオンプレ概念を引きずるのはナンセンス？

クラウド

クラウドやアプリのイメージ

ソニー・ミュージックエンタテインメントでクラウドエンジニア兼プログラマーを務めているしんろくです。よろしくお願いします。

本稿では、クラウド時代における、いわゆるアプリケーションレイヤー開発チーム（以下、アプリチーム）と、インフラレイヤー設計／構築チーム（以下、インフラチーム）の役割分担の意義について考えてみたいと思います。

クラウド以前の役割分担はどうだったか

AWS（Amazon Web Service）、Azure、Google Cloudなどのパブリッククラウドが台頭して久しい現代においても、オンプレミスサーバー構築には、当然ながら一定以上の需要があると思います。

オンプレミスサーバーでのシステム開発がまだ盛んだった時代、システム開発におけるサーバーのスペック選定と調達、設置やケーブルの配線、さらにはOSやミドルウェアのインストールにいたるまでの作業はインフラチームの仕事でした。中でもスペック選定は、どのようなシステムを構築するのか、どのようなアプリケーションが動作するのか、どのくらいの通信帯域が必要になりそうか、などさまざまなパラメーターを、アプリチームとともにディスカッションして決定していく重要なもの。アプリチームは、こうしたディスカッションを経て設置されたサーバーを最大限活用するため、アプリケーションのチューニングを行い、パフォーマンスを最大化するソフトウェアの開発を行っていました。

「安く、早く」を実現できるクラウド時代になって発生した新たな問題

少し話がそれますが、我々ソニーミュージックグループは一部の部門を除いてシステムエンジニアは限られた存在でした。そうした体制下で求められるのはシンプルに「安く、早く」です。「安く」は費用であり、「早く」は納期の意味合いが大きいです。そのような文化があるため、Webを通じたサービス展開やアプリケーション開発は当然のようにクラウド環境へシフトしていきました。

クラウドが認知され始めたころは、オンプレよりも「安い」ことに、みなさん満足していたかと思います。従量課金は費用計算が難しいですが、固定資産管理の不要性とサーバースペックの可変性による業務効率化は期待以上の効果を発揮しました。

その後、クラウド上でのサービス開発が当たり前になってくると、次は当然のごとく「早く」が求められるようになります。これもクラウドの性質により、サービスを「早く」開発することができるようになり、オンプレではできなかったサーバースペックのスケールアップ／ダウンも素早くできるようになりました。

そうして「安く、早く」が叶えられた後、そこには「（お金さえ出せば）ほぼ無尽蔵のサーバーが数分で使えるようになる」という感覚が残りました。これはクラウドの性質として正しい捉え方である反面、危険な思想であることは現場で活躍されている皆さんには共感していただけるかと思います。

アプリチームから「なんかアプリの動作が重いので、原因はよくわからんけど、とりまスペックアップよろしく！」という恐ろしい呪文が唱えられ始めます。

資源が有限なオンプレゆえにアプリケーションパフォーマンスを極限まで磨き込んでいく時代は終わりを告げ、パフォーマンスの問題はお金を出して（サーバースペックを上げて）解決してしまえという時代に突入しました。当然ながらインフラチームとしては「そんなにリソースを食いつぶすアプリケーションなら設計から見直せ、実装見直せ」という思いに駆られますが、たしかに短納期の場合にもっとも効率的な解決策は、お金を出してスペックを一時的に増強することです。

ただし、サーバーのスペックアップ／スケールアウトでその場がしのぎきれれば御の字ですが、しのぎきれなかったときは最悪です。費用をかけたにも関わらずエンドユーザー体験は損失され、フラストレーションが蓄積していきます。最終的には事故にもつながりかねません。

オンプレ時代にこういうことが起きたとすると、アプリチームもインフラチームも「想定以上のアクセスだったね」「パフォーマンス改善しなきゃね」と穏便な意見交換がなされるのですが、クラウド時代では「インフラの性能が悪い」「アプリの作りがダサい」という罵り合いに発展してしまうことが多いようです。

クラウド時代になって「安く、早く」が実現できるようになったのに対し、アプリチームとインフラチームの対立が目立つようになってしまったのは、残念でなりません。ぼくらが考えるべきは互いのチームの欠点ではなく、クリエイターとエンドユーザーの感動体験であるべきだからです。

クラウド時代にも適用され続けたオンプレ概念

ぼく自身は長いことLinuxにふれてきましたけれども、実はチームでアプリケーションを開発したりインフラを構築したりという経験がほとんどない状態でソニーミュージックグループに入社しています。また、入社後もWebサービスをひとりで設計し実装しなければならないケースがいくつかありました。そうした現場では、そもそも「アプリチーム」とか「インフラチーム」とかいう区別がなく、アプリ設計も実装も、サーバースペック選定も機器の調達も配線も、OSやミドルウェアのインストールから設定も、全部“同列”です。

ですので、パブリッククラウドを利用し始めた時は「機器の調達も、OSやらミドルウェアのインストールもやらなくていいだなんて、クラウド便利や！」と思った次第です。

もっとも、クラウドの真骨頂と思っているInfrastracture as Code（IaC）が汎用プログラミング言語に対応するのは、ぼくがクラウドに従事し始めてから数年後の話になるので、その間はまだ、ソニーミュージックグループの多くのプロジェクトにおいて「アプリチーム」「インフラチーム」というオンプレ概念がクラウドにも適用された状態が続いていました。

実例で見る「アプリ」と「インフラ」の曖昧さ

では、どうすればそうしたオンプレ時代から続く概念を取り払うことができるのでしょうか？

ソニーミュージックグループではAWS、Azure、Google Cloudなどのパブリッククラウドをプロジェクトごとに利活用していますが、ぼくの主戦場はAWSでありますので、ここではAWSを例に、まずは「アプリ」と「インフラ」の区別の曖昧さについて見ていきたいと思います。

以下、各種フレームワークやライブラリ、AWSのサービス名などが登場しますが、個々の説明は本質的ではないため割愛させていただきます。

はじめにクラウドアーキテクチャを代表するLambdaを例にあげます。

AWS Lambda は、サーバーレスでイベント駆動型のコンピューティングサービスであり、サーバーのプロビジョニングや管理をすることなく、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行することができます。（引用元：https://aws.amazon.com/jp/lambda/ ）

これを従来のアプリチーム／インフラチームの区分に当てはめて考えてみると、どちらの責任範囲になるでしょうか。

  • 実行されるコードはアプリチーム？
  • どのCPUで実行する？
  • デプロイするのはインフラチーム？
  • メモリ量の設定は誰が決める？
  • タイムアウトの設定は誰が決める？
  • ネットワーク設定は誰が考える？

そのほかにもいろいろと考えるべき事柄が出てきますが、アプリチーム／インフラチームとして区別しなければ特にややこしくなることはなく、サービスを設計した人・コードを書いた人が正しく観測し適切な値を設定すればよいだけです。

こう書くと「なんだ、アプリチームの領域じゃん」と思われるかもしれません。たしかに、メモリ量の設定や実行時間のタイムアウト設定、はたまたネットワーク構成などは、オンプレ時代で言うとインフラチームに属する話でしたが、クラウド時代においてはアプリチームも一定のインフラの知識が必要になるということです。

import { aws_lambda as lambda, Duration } from 'aws-cdk-lib';
import { IRole } from 'aws-cdk-lib/aws-iam';
import { RetentionDays } from 'aws-cdk-lib/aws-logs';
import { ServiceBase } from './service.base';

export class LambdaService extends ServiceBase {
  #counter = 0;
  /**
   * @description Lambdaを定義する例
   */
  public createHandler(role: IRole): lambda.IFunction {
    return new lambda.Function(this.scope, this.id('Handler', `${this.#counter++}`), {
      code: lambda.Code.fromAsset('dist/lambda'),
      handler: `main.handler`,
      runtime: lambda.Runtime.NODEJS_18_X,      // ランタイムは何使う？
      architecture: lambda.Architecture.X86_64, // CPUは何使う？
      logRetention: RetentionDays.TWO_WEEKS,    // ログはいつまで残す？
      role,
      timeout: Duration.seconds(10),            // 実行時間のタイムアウトは？
    });
  }
}

AWS CDKを用いたLambdaの定義例

Lambdaを定義するだけでもアプリの話なのか、インフラの話なのか、が混ざってくることがわかります。

続いての例はS3です。

Amazon Simple Storage Service (Amazon S3) は、スケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。（引用元：https://aws.amazon.com/jp/s3/ ）

S3はオブジェクトストレージサービスですが、このS3を単純に何でもいれられるストレージとして利用するか、一定の規則をもったデータベースのように利用するかで話が変わってきます。

前者の場合は、特に何かを気にすることはあまり無いかもしれませんが、重要になるのはストレージ種別によるコスト管理でしょう。アクセス頻度の違いによるコスト圧縮の観点はクラウドサービスを利用する上で重要な指標のひとつとなります。

S3を使ってログを集約し解析するといったデータベース（データレイク）のような使い方の場合は、アプリケーションやサービスの要求に対し格納するオブジェクトキーを設計しなければなりません。また格納するファイルのフォーマットの違いによるパフォーマンスの差も出てきます。あえて区別をつけるとすると、インフラチームの領域というよりもアプリチームの責任領域と言えます。つまり、クラウドストレージサービスひとつとっても、その扱いはアプリケーションの設計に依存することになります。

コンピューティングサービスであるLambda、オブジェクトストレージであるS3はサーバレスアーキテクチャを構成するためによく使われるサービスですが、サーバレスアーキテクチャにかぎらず、LAMP（Linux, Apache, MySQL, PHP）構成を実現するためのサービスにもこの話は当てはまります。

LAMP構成のうち、マネージドサービスとして展開されているのはデータベース層であるRDSです。

Amazon Relational Database Service (Amazon RDS) は、クラウド内でデータベースのセットアップ、運用、およびスケールを簡単に行うことのできるマネージド型サービスの集合体です。（引用元：https://aws.amazon.com/jp/rds/ ）

RDSを利用することで、旧来のインフラチームはサーバー機器の調達からOSのインストール、DBMSのインストール、ネットワークの設計から開放されます。旧来のアプリチームは用意されたデータベースを利用してアプリケーションを構築するのですが、アプリケーション側でのパフォーマンスチューニングが十分に行われていない場合、アプリケーションの性能を見直すか、インフラ側のスペックアップを要求するか、選択することになります。

先にも述べた通り、オンプレ時代では限られたリソースしかなかったため、アプリケーション性能を見直す選択肢が取られることが多かったのですが、クラウド時代に入り、その場しのぎの「とりあえずスペックアップ／スケールアウト」という選択肢が取れるようになったことは、喜ばしいことでもあり好ましくない現実でもあります。

クラウド時代のエンジニア像とは？

ここまでクラウド時代におけるアプリチームとインフラチームの存在意義について思いを馳せてきましたが、ぼく個人は、アプリチーム／インフラチームの区分そのものがナンセンスだと思っており、そのような区別したチームを構成していては、クラウド環境を十分に活かしきれないまま、月日とお金が流れていくのだろうなと感じています。とはいえ、チームや組織で仕事をする以上、なんらかの責任領域を決めておいたほうが無難であることもわかっています。

ではアプリチームとインフラチームはそれぞれどのようなチームとなればよいかと考えると、

  • アプリチーム：コンピューティングやストレージ等各種リソースの性能要件まで責任をもつ
  • インフラチーム：サービスが要求する仕様に対し、最適な構成を考え、コスト管理まで行う

というところかなと考えています。

「アプリしか興味ない」とか「インフラだけやっていたい」という方々もいらっしゃるかと思いますが、システムやサービスを開発したいと思ったとき、どちらか一方だけの知識ではなく両方の知識と経験を有していることで、必然的に仕事に巡り合う可能性が高まり、結果的にユーザーにとって「おもしろいもの」を創る機会が訪れるようになると確信しています。エンタテインメントというロジックでは測りづらい漠然とした業界で、おもしろいものを、いかに早く、いかに安く提供できるか。それこそが、自分の目指すクラウドエンジニア像です。そこに至るためには、「アプリ」とか「インフラ」とか区別している時間がもったいないですよ、というお話で本稿を締めさせていただきます。

以上、ありがとうございました。