見出し画像

Day3「クラウドネイティブとは?クラウドネイティブの進め方。」 @ ガバメントクラウドについて考えるAdvent Calendar 2022

この記事は、ガバメントクラウドについて考える Advent Calendar 2022のDay3「クラウドネイティブとは?クラウドネイティブの進め方。」となります。

※こちらの記事は基本的には公開情報を元にしていますが、個人的な妄想・意見も含まれておりますので、ご承知おきください。

このAdvent Calendarは、日々活動している中で課題として感じることなどをどこかで整理しなくてはいけないと思っていて、ちょうど良いタイミングだったので、全日自分が思うところを書くというスタイルにチャレンジして、どこまで続けられるかやってみたいと思います。
https://adventar.org/calendars/8293

以前、以下のツイートに多くのことをまとめてみたのですが、改めて整理していきます。

クラウドネイティブとは?

ガバメントクラウドで取り沙汰されているクラウドネイティブってそもそも何なんでしょうか。多くのことはDay1の記事に書いてしまったので、こちらをご覧いただくと大枠は掴めるのではないかなと思います。

そもそもクラウドネイティブが求められる背景

そもそもクラウドネイティブなアプリケーションが求められる理由についておさらいしておきましょう。ビジネスの世界では、様々な要件が求められ、速いスピードで要求されることから、それらに応えていかなければ競争に勝てず、生き残っていけないという状況があります。これらに対応するためには、アプリケーションをどんどん書き換えながら、素早くリリースしていくことが求められています。そんな中でも、そのアプリケーションのセキュリティや安定性も求められていくので、自動化され高度化された仕組みというもので、アプリケーションの改修を行っていかなければなりません。

クラウドネイティブを実現する技術実装

ではこのビジネス速度に対応するアプリケーションの改修のために必要な技術実装とはどのようなものかを整理します(今回は、一般的なものを紹介します。)

まず、今までは開発環境のセットアップをサーバー側で行って、ソースコードを書いて、属人化されたセキュリティ対策が行われ、プログラムが実行可能な形にビルドされ、テストの後、本番環境にも同様の環境を作って、今までのアプリを入れ替えるという流れを取っています。

環境構築が手作業だとOS、実行環境、利用しているライブラリ、セキュリティパッチなどによって動作が変わってしまったり、テストするのも難しくなります。また、セキュリティ対策が人によって属人化すると、考慮漏れが発生したり、脆弱性のアナウンスがされた際に、自分たちのどこにそれが影響するかを把握するところからスタートになってしまい、対応に時間がかかります。このようなことを回避するために本番環境への提供は、入念に準備され、年末年始などといった業務影響が少ない期間に慎重に実施することが多かったと思われます。しかしながら、このようなやり方だと、先のビジネス背景に応えることが非常に難しいということはおわかりいただけると思います。

そのため、ビジネス背景に応えようとすると、この開発プロセスを変えなければならないといけないということになります。例としては、開発環境も本番環境も、バラバラになってしまいがちな環境を環境構築をコードで統一化して、差異がでないようにするであるとか、テストを自動化し、誰がおこなっても必ず同じセキュリティの観点を考慮したアプリケーションが作れるようにするということが、今は実現できるようになっています。本番環境へのデプロイも、徐々に入れ替えるであるとか、ダメだったらすぐ戻せるようになっていて、入念に準備して入れ替えるというよりは、入れ替えてダメだったらすぐ戻せるのでどんどんトライしていこうというものになっています。

このように開発速度や開発体験の向上を、自動化を通じて速度向上させることによって実現するということがアプリケーション開発においても求められているということになります。

クラウドネイティブを実現する技術の違い

今までの内容を実現するためには、今までと同じ技術を使っていても難しいです。クラウドネイティブを実現する技術の代表は、コンテナであったり、サーバレスに代表されるようなマネージドサービスになると思います。

マネージドサービスのようにクラウドサービスが提供してくれるものを利用すれば、環境構築という観点が大幅に簡素化され、さらに共同利用により従量課金の支払いになるため、どれだけ使われるかわからないシステムであったり、利用料が増加しても自動的にスケールしてくれたりと、先のビジネス背景においては非常にマッチした環境を手に入れることができます。Day1の記事でも述べましたが、それが故にクラウドが提供するサービスをよく知り、それに合わせた開発をする必要があり、別のクラウドで同じように動かせるかというとそうはなりにくくなります。また、そのサービスの仕様に依存することになり、対応していないプログラミング言語やフレームワークといった壁にぶつかることも考えられます。つまり、クラウドサービスに依存することにはなるんですが、インフラ部分が省力化されるようなイメージです。

一方、クラウドネイティブを実現する技術として、コンテナと呼ばれるものもあります(もう少しDay4で解説します)。これはその仕組の俊敏性を生かして、一気にスケールしたり、必要のないときは消すといったことがしやすい技術です。先のマネージドサービスもクラウドサービス事業者としては、裏側の技術としてコンテナが使われていることも多いと思います。しかしながら、コンテナのプラットフォームなどは、クラウド上でも自分で整備・運用する必要があります。その代わり、先程のプログラミング言語やフレームワークの壁にぶつかることも少ないですし、マネージドサービスの仕様というものに縛られることが最小化されますので、プライベートクラウドやパブリッククラウド間で柔軟性があるアプリケーションを開発できるという特徴があると言えます。つまり、コンテナはクラウドにオープンなのですが、ある程度の自前運用が必要という位置づけだと思います。

マネージドサービスとコンテナの違い

マネージドサービスとコンテナのどちらが良いというつもりは全くありません。逆にどちらにもユースケースがあるから存在しているわけで、どちらも否定されるべきではありません。これらの特徴をインフラのエンジニアが理解することはなかなか難しかったので、私も個人的にWebサービスを作ってみるということを通じて、これらを理解してみようとした結果を共有したいと思います。

まず、私のように個人で何かを開発するときに最適なのはマネージドサービスだと非常に感じます。私はFirebaseを使って個人開発をすることが多いのですが、APIのサーバーやデータベースを作るのはコマンドラインでもGUIでも可能で、そのスケールや運用保守はすべてGoogleでおこってくれます。

コンテナの場合は、コンテナを立ち上げるOSを作って運用するか、CaaS(Container as a Service)を使って運用するかになり、環境構築・運用に手間がかかるため、少人数でビジネスに集中しなければならないシチュエーションでは減らしたい手間になりますので、このようなマネージドサービスを使いたいというのは当然の方向性です。料金的にもよほどのアクセスが来るまでは無料に近しい料金で運用できます(その代わり、アクセス量が増えたときには高いと言われていたりします。)

しかしながら、FirebaseのデータベースはRDBではありません(つまりは、SQL文で通信できないということです)。そのため、データベースやソースコードをそれ用に合わせなければなりません。また、APIサーバーはNode.jsというJavascriptベースの言語を利用しなければなりません。つまり、PHPやそのフレームワークであるLaravelを使おうとした場合は、新たにNode.jsに書き換えるか、コンテナを使って自由に言語選択できるようにしなければなりません。

このように、今自分が使っている言語や技術といったものによって、マネージドサービスやコンテナのどちらを選択するかという判断も変わってくるでしょうし、これからどうしたいかやビジネスの成長に応じて選択も変わってくると思います。

明日、もう少しコンテナについて解説しようと思いますが、本日のお話を聞いて皆さんは、ガバメントクラウドの対象システムである政府系のシステムについて、クラウドネイティブが最適なのかどうなのかについてはどう思いましたか?政府システムの中でも、これから作るアプリケーションや既存アプリケーションもあり、既存アプリケーションの中でも変革が求められているものとそうでないものもあるでしょうし、全部に取り組むにはお金も人材も確保できるのかという状況下において、今一度考えてみても良いかもしれません。

執筆後記

このようにガバメントクラウドを考えるAdvent Calendar 2022では、以下の流れで進んでいくことになると思いますので、Day2以降もお待ちいただければと思います。

  • ガバメントクラウドの在り方

  • ガバメントクラウドの整備における課題感

  • ガバメントクラウドの利用における課題感

  • ガバメントクラウドの今後について考えてみる

Twitterなどで情報発信していますので、もしよろしければ覗いてみてください。