Help us understand the problem. What is going on with this article?

【DevOps試験対策#1】マルチクラウドプラットフォームの是非を問う

概要

標題については私自身も結論を明確に出せていない。
近い将来、それぞれのパブリッククラウドが明確な棲み分けが出来るようになる、もしくはインフラという概念が希薄になってきている昨今、俗に言うフルスタックエンジニアがもう1歩、2歩先に見える将来像に到達した時には、間違いなくマルチクラウドプラットフォームは是である。と言えるかもしれないが、現状では必要要素が多く、全てのパターンにおいて必ずしも是であるとは言い難い部分も内包されている。

それらを踏まえた上で本稿では「あえて是であるという論調」で進めて行きたいと思う。

さて、Kubernetesについては実際の業務でかなり触れていたが、そろそろ資格でもとってみるかということで
受験勉強をしてみようと思う。
業務で触れていたのは、AWS, GCP, Azureと著名なパブリッククラウドでマルチクラウド環境を作り、利用する側のUIを統一するためにKubernetesで抽象化を行いました。

なので試験対策そのものはGCPからスタートではありますが、AWSやAzureについても受験をする予定です。

今回、Qitaを使ってマルチクラウドプラットフォーム化で感じたことと試験対策の内容を書き綴っていこうと思う。
いくつまで更新するかは現時点では未定であるが、結構な長編になるのではないかと思っている。

マルチクラウドプラットフォームにおける課題

作成するアプリケーションの特性やサービス提供ユーザーに併せて最適な環境を選択出来るという点では、
マルチクラウド環境は素晴らしい成果を上げますが、SREとしての立場としては様々な仕様を把握したり、仕組みが複雑化するという問題点もある。

例えば、とあるパブリッククラウドAのサービスで素晴らしいものがリリースされた。
今回計画しているアプリには、このサービスを利用するのが最適である。
だがしかし、現状プラットフォームとして利用しているのはパブリッククラウドBである。

新規でプラットフォームを作り上げるには、様々なハードルを乗り越える必要がある。
ハードルの種別は各社様々だと思うが、まずはコスト、運用手順の煩雑さ、この2つが乗り越える必要がある大きな壁だろう。

まずコストだが、上記のような状況でアプリ単体での収支を見ると新たにクラウドプラットフォームを導入するにはコスト感が合わない場合が多い。

ホームページ程度であるなら別だが、アプリを継続的にリリースしている会社であればあるほど
既存システムとの連携や業務システムとの連携、セキュリティ対策などアプリケーションを支える様々な仕組みを新たに構築する必要が出てくる。

これらのリソースを単なるコストとしないために複数のアプリケーションを新プラットフォームへデプロイしていく計画を立ててキーマンの承認を得る。というのが現状だと思う。

だがしかし、この手法で行くと最初の頃はそこまで煩雑化しないが、数年立つとプラットフォームA担当、B担当など担当の細分化が必要になったり、Aしか担当しないから見えない効率化方法、Bしか担当しないから見えない運用手順の煩雑化、AとBでそれぞれ別のオペレーションになったり、別ツールを使うなど多くの闇を抱えることに結果としてなりがちである。

次に運用手順の煩雑さだが、運用しているアプリの数、使っているツールの数、利用しているパブリッククラウドの種類が多くなるほど手順は複雑化しがちである。
定期的に手順やフローなどの標準化チェックを行い、各人が共通認識を持ち、特殊なフローを作らず、より簡素化へより標準化へと邁進し、しっかりとしたフローの中で進めて行くこと。

これらの前時代的感覚の弊害としては、一言でいうなら柔軟性にかけるということである。
DevOps関連のツールやミドルウェアは日々進化しており、それらを柔軟に取り入れるためには、まず使ってみようというチャレンジが必要となってくる。
ITの進歩は目まぐるしいので、世により良いものを提供していくためには柔軟性は必要不可欠といえる。
「新しいものを導入するにあたって、どれほど苦労するかわかってる?」などといった批判が聞こえてきそうだが、
アプリ自体は定期的に改修されるし、インフラは5年もたてば刷新しなければならない、クラウドであるならばもっと短いタームでの刷新が必要になる場合もあるだろう。
それに併せて運用部門についてもどんどん変革をしていかなければならない中で苦労を大上段に構えて変革を拒絶するのはナンセンスではなかろうか。

ただし、言わんとすることもわからなくもない。
ありがちなパターンでいうと開発部門やインフラ部門の「まず使ってみよう」という音頭で初めて使いっぱなしで終わるパターンがある。
結果として運用部門の人が苦労をして運用手順を立てつけたという話はよく耳にする。

新しいツールやミドルウェアを取り入れるにあたって、どの部門の方が「まず使ってみよう」と言い出すかは様々であるが、
最終的に運用部門に落とし込んで行く必要があるが、そこを忘れがちな人が多いのも事実である。

最終的に出てくる話としては、1つのパブリッククラウドですらしっかりとしたフローを回して共通認識を持てないのにマルチクラウドプラットフォームなんてとんでもない。といった結論に陥りがちである。

もちろん開発部門やインフラ部門の方も新しいツールやミドルウェアを利用することに難色を示す人もいるだろう。
理由は様々であるが、今は時間がない、メンバーの入れ替えが生じたのでまずは既存の業務を覚えることが優先、大型のPJが動いているので対応する人員がいない。といったところだろうか。

簡単に言うとプライオリティの問題とワークロードの問題である。
その他にも推察出来る要素は複数あるが、多くの方が挙げられる問題点は上記になるであろう。
この手の問題はマネージメント層の手腕で解決する以外に方法がない。

仕事には(仕事以外でもだが。)下記の4つがあると思う。

1. やらなければならないこと
2. やったほうが良いこと
3. やらないほうが良いこと
4. やってはならないこと

1をやるのは当然ではあるが、2については放置をすること自体は4に該当する場合が多い。
結論として1を間断なくやりながら2についてもしっかりと進める。
そのために業務負荷が上がるのであれば人の手当をするなど解決策はいくらでもある。
この時に人の手当が出来ないのであれば、それはマネージメントの問題となるであろう。
そのための人の確保であれば昨今ではSREという概念も定着しつつあり、SREの採用に積極的な会社も多数ある。

課題の整理

さて、ここで課題を整理したいと思う。

  1. コスト
  2. 煩雑化(闇を抱えかねない。)
  3. 柔軟性は必要不可欠
  4. 運用まで考慮に入れた変革が必要
  5. 優先度
  6. 業務負荷

如何でしたでしょうか。
この投稿で少しでも各社様のIT部門がより良い変革がもたらされることを祈っています。

それでは次回をお楽しみにお待ちください。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした