4. クラウド業界の動向
ここでは、クラウド業界の動向についてお伝えします。筆者がこれまで、ある程度の立場でプリセールスやコンサルタントをしてきたことを踏まえて、主に金融業界のクラウド案件に対するエンドユーザの見解、という観点からお話しをさせて頂きます。
一言でいうと、クラウドの勢いはまだまだ強いです。
今からシステムを検討する場合、どこの会社もまずはクラウドを第一に検討する「クラウドファースト」の時代ではないでしょうか。
金融業界も、クラウド導入の初動は他業界に比べると遅れましたが、現在はクラウドファーストの考えが浸透していると言えるでしょう。
金融業界がクラウドへシフトできた大きな理由の一つとして、AWSやAzureなどの各クラウドから、FISC（The Center for Financial Industry Information Systems）への対応方針が明示されたことが考えられます。
また、AWSやAzureのサービスも、金融業界への導入を意識してなのか、金融業界への導入が開始され始めたころからマネージドサービスのセキュリティ強化をこぞって行いました。
パブリッククラウドはインターネット経由の接続が前提であるにも関わらず、如何にインターネットに出ないか、もしくは如何にパブリッククラウドにプライベートな環境を構築できるかがセキュリティ強化の焦点となり、それをクリアしていくことで金融業界への導入も加速してきました。
次に、オンプレとの互換性についてお話します。
パブリッククラウドに移行する上で、切っても切れないのがオンプレとの連携です。
先にも述べましたが、オンプレに保守運用基盤があり、クラウドにシステムを移行するけれども、保守運用はオンプレから行う、というパターンが非常に多いからです。
この話は金融業界で顕著に現れますが、製造業界や一部のエンタープライズのお客様でも、比較的一般的な構図になります。
それに対して、近年、AWSはOutpostsというサービスがリリースしました。
これは自社DCなどにプライベートなAWS環境を構築できるというサービスです。
https://aws.amazon.com/jp/outposts/
このサービスを活用すれば、すべてをオンプレで解決できることになり、セキュリティレベルが高いお客様もクラウドを採用することが可能になりました。
一方、AzureもAzure Stackという同様のサービスを提供しています。
https://azure.microsoft.com/ja-jp/overview/azure-stack/
詳細な説明は割愛致しますが、近年のクラウド業界の動向として、アメリカのペンタゴンのクラウド契約の話題があります。
100億ドル規模になる軍のコンピュータを一新するJEDIプロジェクトの契約先として、最終候補になったのはAWSとAzureです。
当然のことながら、セキュリティレベルはトップクラスに高いものを要求されます。その要求に応えて権利を勝ち取ったのがAzureでした。
一部では、Azure stackの導入実績が功を奏したと言われています。
この例に見られるように、パブリッククラウド上にシステムを作るのではなく、自社のオンプレ上にパブリッククラウドを作る動きが出始めています。
また、国内のみならず、世界でもAWSのシェアは大きいですが、このプロジェクトの行方次第ではAzureの巻き返しが大いにあるのではないかと考えています。
最後に、最新の技術動向についてです。
従来は、IaaSやPaaS主流のシステム構築が中心でしたが、近年になって、コンテナ技術が注目を浴びています。
コンテナとしては、DockerやKubernetesなどのキーワードを聞いたことがある方もいらっしゃると思います。近年、このコンテナ技術を活用してシステム構築をする動きが加速しています。
詳細は割愛させて頂きますが、コンテナ技術とは、1つのホストOS上でアプリケーションを完全に分離し、動作させることを可能にする技術です。これを利用することにより、あたかも複数のOSが存在するかのようにアプリケーションを動作させることができます。そのため、プラットフォームの影響を受けることなく、オンプレでもクラウドでも、環境を選ばずに同じ動作をさせることが可能です。
このメリットを生かしたRedhatのソリューションであるOpenshiftが、金融業界をはじめ、各業界で実績を伸ばしてきています。
その他、Kubernetesを活用したAWS EKSやAzure AKS、GCP GKEなど各クラウドベンダーがコンテナのマネージドサービスを展開しています。
コンテナ技術を活用したシステムとしては、Netflixをはじめ、国内ではメルカリやクックパッド、ポケモンGOなど大規模システムでの運用実績があります。
金融業界でもコンテナへのシフトに積極的です。海外では、Bank of Americaやドイツ銀行、マッコーリー銀行など大手銀行がコンテナへのシフトを提唱しています。
個人的には、金融業界はあまり最新技術を使わない（使いたくない）イメージがあるのですが、コンテナに関しては、前のめりで検討をしている状況です。
コンテナ＋マイクロサービスは組み合わせの相性が良く、自動化を行ってコストを削減していくことを目的に、様々な業界で検討が進められていると感じています。
今後、このコンテナ技術はクラウド業界のデファクトスタンダードになっていくのではないかと筆者は見ています。
5. クラウド業界におけるインフラエンジニアの位置付け
従来のインフラエンジニアの作業イメージは、DCへのサーバの導入やHW周りの設定、OS設定、DBや一部MWの設定などが中心だと思います。
では、クラウドへシフトした中で、インフラエンジニアの位置付けはどうなるのか、ということについてお話します。
まず、特定の業界で位置付けが違うということは余りないと思います。
クラウドの構築においても、IaaSのシステムであれば、VMのデプロイからOS設定は必要になります。また、AWSやAzureなどでは、AWS CloudWatchやAzure Monitor、バックアップなど、非機能周りの設定もすることになります。
扱うサービスや設定方法は違えども、OS設定や非機能周りの運用監視設定から一部MWの設定をするところまでは、従来通りインフラエンジニアの守備範囲になります。さすがに、HWの導入はありませんが、インスタンスのサイジングなどは担当しなければなりませんし、パフォーマンステスト等でパフォーマンスが出ない場合は、VMインスタンスのスペックを上げて対処するなどはよくある話です。
そのため、これらの技術知識は、従来のオンプレ構築の際に培ったものが役に立つと思います。
一方で、近年はInfrastructure as Codeの考え方の浸透やIaaS、PaaSの構成管理の観点から、コードでシステム管理を行うことも少なくありません。
インフラの構成管理のツールとして、AnsibleやTerraformなどを使い、コードで構成を管理し、デプロイすることで構築の自動化や効率化を図ります。
また、AWS Lambdaで例えますが、Lambdaで実行するスクリプトの開発はインフラエンジニアが担当する場合もありますし、LambdaはPaaSであり、スクリプトはPythonで記述することも多々ありますので、PaaSは一概にアプリケーションエンジニアで対応するということもありません。
その点で、インフラエンジニアとアプリケーションエンジニアの境目が薄れてきており、インフラエンジニアでもPythonなどのコードを記述できないとクラウドをフル活用できないという点では、従来との位置付けが変わってきていると感じます。
6. 実案件をベースとしたインフラエンジニアの働き方
それではここで、実際のクラウド案件として金融業界の比較的規模の大きなシステム構築を想定して、インフラエンジニアの担当領域についてご紹介したいと思います。
開発手法は、一般的にウォーターフォール開発で行われます。
要件定義フェーズのインフラエンジニアの担当としては、
- アプリケーション部隊と連携してのグランドデザインの設計
- 従来（オンプレ）の要件定義をもとに、クラウドで置き換えた場合の要件の整理
- オンプレではない、クラウド特有の要件の整理
- クラウド利用時のランニングコストの概算見積
- PaaSを使う場合は、PaaSとアプリケーションの互換性確認（主にDB等）
などが中心になります。
ポイントはクラウド特有の要件の整理になります。
金融業界の場合は、やはりインターネットに出るのか出ないのか、という部分を非常に気にされるので、クラウドの各サービスを利用する際に、セキュリティ面の安全性を説明する必要があります。
このとき、クラウドの知識と勘どころがないと、顧客折衝は厳しいかもしれません。
また、PaaSを使う場合は、何かと技術的な制限がありますので、上物のアプリケーションが正常に動作するのか、という点は、アプリケーション部隊と事前に認識合わせをする必要があります。
もう１つ事前に整理するべきなのが、バージョンアップについてです。
クラウドのサービスを使う場合は、基本的にクラウド側が自動でバージョンアップを行います。
従来のシステム運用の場合は、OSやDBのバージョンのサポート切れに伴い、バージョンアップを計画して実行する、という流れだと思いますが、クラウドの場合は、ユーザー都合を考慮せずにバージョンアップが始まってしまう場合があります。
その際は、いきなりバージョンアップされるのか、事前に通知が来るのかなどを整理したうえで、通知される場合はどのようにシステムとして対応していくのか、保守体制をどうするのか、といったことを顧客と整理しておかないと、運用フェーズで問題が起こる可能性があります。
これらはすべてクラウド特有の要件整理となりますので、これらを理解した上で案件を遂行していく必要があります。
その他、細かい部分や案件特性により、クラウドの知識は色々と要求されます。
要件定義フェーズが終わると、基本設計、詳細設計とフェーズが進行していきますが、各設計フェーズでやることは、要件定義に従って設計要件を詰めていくということになるため、オンプレでもクラウドでも変わりはありません。
案件を遂行する上ではある程度の経験値も必要とされるため、転職時に各社でクラウド案件の経験値を求められるのも必然となるのは頷けます。