パブリッククラウドの利用料に関しては、パブリッククラウド特有の従量課金方式をいかに効果的に活用できるかがポイントとなります。コスト削減効果を最大限にするために、利用量に合わせてスケールアップ(垂直スケーリング)、もしくはスケールアウト(水平スケーリング)が可能なシステムを検討することになるので、開発者は要件に合った作り込みをすることになります。ただし、利用量の変動が小さいシステムに対するスケールアウトの検討では開発側の負荷に比べて、コスト削減効果があまり出ない場合もあるので、利用予測を十分おこなっておく必要があるでしょう。

パブリッククラウドでは従量課金以外にも、前払いや一定期間内での一定量の使用の約束、余剰インスタンスの入札などにより、低コストで利用できる割引プログラムが用意されているので、開発者は利用予測や従量課金単価、割引プログラムなどを総合的に判断して、アーキテクチャを決める必要があります。
前払いに関する割引プログラムの適用については、契約期間を長く設定した際、その間に従量課金単価の値下げがおこなわれる場合や、後から提供が開始された高性能なサービスに切り替えた方がコスト削減を見込めるケースもあるので、この点も注意が必要です。

従来のオンプレ環境のインフラの見積もりでは、ハードウェア構成についての専門知識を有するインフラ担当者が対応する必要がありましたが、パブリッククラウド環境では専門知識がなくてもマネージドサービスの課金体系を理解していれば、開発者でもコストの見積もりが可能です。
また、パブリッククラウドでは、利用状況を確認できるツールが提供されており、各マネージドサービスのログやメトリクスを簡単に取得する仕組みも強化されているので、それらの統計データの傾向分析をおこなうことで分析作業の負荷を抑えながら、効果的な割引プログラムの適用について検討ができます。
さらに、必要な時にだけリソースを作るDisposable Infrastructureの考えが取り入れやすくなり、より柔軟なシステム開発が展開できるようになったことも特徴的な点です。

人件費

人件費については、これまでオンプレ環境で必要としていたインフラチームの体制をいかに縮小できるかがポイントとなります。また、パブリッククラウド環境では、技術領域の役割分担がこれまでの考え方と大きく異なるため、従来のスキルセットしか持たない担当者を無意識に配置することがないよう注意が必要です。

オンプレ環境のインフラ構築では専門領域（ネットワーク／セキュリティ／OS／DB)ごとに担当者が配置されていましたが、パブリッククラウド環境ではマネージドサービスの動作が仕様で決められています。そのため、これまでインフラ担当者が柔軟に設計することできた作業範囲が減ることになり、専門領域別に担当者を配置する必要性が失われつつあります。
つまり、マネージドサービスを利用することで開発者でもインフラ領域の設計が可能となったため、専門のインフラ領域のみを扱うインフラ担当者を配置しない分、コスト削減が実現できることになります。また、マネージドサービスの問題発生時はインフラ担当者を介さずとも、開発者が効率よく対応できるようになる点もメリットとして挙げられます。

開発者がインフラ領域を対応できるようになった要因として、インフラ領域の専門知識の縮小以外にサイジング作業の縮小も挙げられます。従来のオンプレ環境ではハードウェアリソースを自前で用意する必要があったため、ライフサイクル期間のピークに耐えられるサイジングをインフラ担当者がおこなう必要がありました。一方、パブリッククラウド環境では料金体系が従量課金となった影響で、利用状況に合わせてリソースの数やスペックを自由に変更できるため、従来のサイジング作業をおこなわないで済むようになったことが要因として挙げられます。
ただし、開発者が利用頻度の低いマネージドサービスの機能まで把握をするのは大きな負担となるため、マネージドサービス全般に深い知見を持つアーキテクトの役割を従来と同様に組織レベルで配置し、各プロジェクトの技術支援をおこなう体制を作ることが重要です。

コンテナの適用判断

これまでマネージドサービスの充実に伴い、新規システムを開発する際にマイクロサービスアーキテクチャの適用を検討すべき理由を解説しましたが、既存システムについてもマイクロサービスアーキテクチャの適用を検討するべきか考える必要があります。
既存システムのマイクロサービス化を進める際には、業務影響を出さないことが最優先事項となります。そのため、マネージドサービスへの切り替えのようなリスクが高い検討は最小限に控えて、まずは既存アプリケーションをパブリッククラウド環境の1つのコンテナに移行するまでを最初のゴールと定めるのがよいでしょう。その後、既存システムに新たな機能を追加する際は、別のコンテナ、もしくはマネージドサービス上に開発をおこない、既存システムと連携させることでマイクロサービス化を進めて行きましょう。

既存システム自体のマイクロサービス化をおこなう際には全機能をリストした後、その中から機能間の結合度が低く、改修する頻度が高い機能を洗い出し、再利用可能な小さい単位に分けて別のコンテナに移す進め方が考えられます。しかしながら、ビジネス影響や費用対効果など総合的に検討した結果、既存システム全体の刷新のタイミングを待った方が良い場合が多いので、重要度の低いシステムのみに限定するなど慎重に進めることを推奨します。

既存システムの場合はコンテナから始めてマネージドサービスへの利用を検討する進め方を推奨しましたが、新規システムの場合は逆の手順となります。最初に改修や機能追加など開発負担の削減効果が見込まれるマネージドサービスの利用を積極的に検討し、仕様上の制約によりマネージドサービスでは実現できない場面では、従来の開発をコンテナ上でおこなう進め方がおすすめです。

上記の進め方はマネージドサービスの検証環境を簡単に用意できるパブリッククラウドだからこそ可能となったと言えます。机上での設計に時間をかけず、実際のマネージドサービスを操作しながら確認をおこなうことで、コンテナへの切り替えの判断を早く実施することができます。

注意点として、専任担当の手配や開発者の学習など長期的な計画と予算の確保が必要なことが挙げられます。マイクロサービス化を進める上でサーバ上のアプリケーション開発と同じように開発が進められるコンテナという選択肢があることはリスク低減に非常に有効ですが、コンテナを扱うにはこれまでより高度な技術力が求められるため、コンテナ利用の際には注意しておく必要があるでしょう。

アジャイル開発との親和性

アジャイル開発とは「変化を積極的に受け入れ、素早くソフトウェア開発をおこなう軽量な開発手法の総称」であり、1つの開発手法を指す言葉ではありません。以下では、アジャイル開発に共通する特徴の中から、パブリッククラウドを中心とした技術・手法と関連がある3つの特徴に絞って親和性について説明します。

短期間の開発を繰り返す

アジャイル開発手法の多くは反復(イテレーション)と呼ばれる1～4週間という短期間での開発を繰り返しおこない、リスクの最小化を目指しています。イテレーションを実現するためには短期間で開発が収まるように開発対象を小さい単位に分ける必要がありますが、マイクロサービスアーキテクチャを採用することで、開発対象の範囲の判断がスムーズにおこなえるようになります。また、マイクロサービス自体が小さい開発単位ですが、マイクロサービス内でマネージドサービスを積極的に活用することで、実際に開発する部分はさらに小さくすることができます。

実際に動作するソフトウェアを重視

アジャイル開発ではイテレーションごとに顧客が判断できるソフトウェアを作成し、実際に動かして確認をおこないます。動くソフトウェアを確認する必要があるので、インフラ環境の構築、アプリケーションのビルド、検証環境へのデプロイを繰り返しおこなうことになります。短い期間でイテレーションを実現するためには、上述の作業の自動化が必須となります。パブリッククラウド環境では、IaCツールやVCSツール、CI/CDツールを組合せて自動化された環境を構築することが容易にでき、この環境を管理する負荷も最小限に抑えることができます。

計画に従うことよりも変化への対応を重視

アジャイル開発ではソフトウェアの要件が変化することを前提にしているため、当初の計画を重視せず、反復の中で毎回開発対象の見直しをおこないます。
要求は変化しますが、反復の単位では要求に沿った動くソフトウェア(機能)が作成されて、徐々に出来上がった複数のソフトウェア(機能)が最終的には連携した1つのシステムとして提供されます。このように要求の変化を受け入れながら出来上がった機能を連携させていく進め方であることを考えますと、マイクロサービスアーキテクチャを採用して各機能を疎結合な作りにした方が品質の観点からはリスクが軽減できるでしょう。
アジャイル開発を進める際、マイクロサービスアーキテクチャを採用するメリットについて説明したが、逆もまた然りです。安易にマイクロサービスアーキテクチャを採用した際、開発する順番やマイクロサービスごとの機能範囲の区切り方が分からず、本来の目的と方向性の異なる開発が実施されるケースがあります。この場合、アジャイル開発の手法を取り入れることで、ビジネス視点での要求の優先度を反復ごとに精査がおこなえるため、問題を回避できます。

アジャイル開発の「変化を受け入れる」という特徴は、パブリッククラウドの従量課金に対しても効果を発揮します。当初決めたアーキテクチャでは要件を満たさないことが判明した場合やアーキテクチャ決定後に非常に有用なマネージドサービスの発表がされた場合、パブリッククラウドでは従量課金による精算ができるため、オンプレに比べて費用を気にせずともアーキテクチャの再検討を実施しやすいと言えます。また、アーキテクチャの再検討は、開発側の負担が非常に大きい行為と言えますが、変化を積極的に受け入れるアジャイル開発の手法を採用することで、その時に最適なアーキテクチャを活用できる機会を得やすくなります。

▼前回の記事はこちら▼
第１回　クラウドネイティブアプリケーション開発とそのアーキテクチャ

ダウンロードはこちら