GCP エンジニアが AWS 案件に参画した話
業務上で GCP の開発スキルしか持っていないエンジニアが、転職して Amazon Web Service（AWS）の開発案件に参画しました。このパターンを私はあまり聞いたことがなく(この逆パターンはよく聞きます)、折角なので、GCP エンジニア目線で AWS 案件に参画した時の両サービスの比較を書いてみました。
（巷には GCP と AWS の比較ネタはたくさんあると思います。）
対象読者
- GCP しか知らない人。
- AWS 有識者で GCP エンジニアが AWS を始めてどう思ったか知りたい人。
- 同じ境遇のエンジニア
GCP と AWS の違い
ここでは、AWS で作業する上で、引っかかったり気になったことを挙げています。
GCP 案件しかやったことがなく、もしかしたらディスりっぽく感じる書き方のところもあるかもしれませんがご容赦ください。
また、特にまとまりなく書いていますがご容赦ください。
アカウント
AWS の場合、アカウントは AWSの契約を指し、AWS アカウントに対してルートユーザー、IAM ユーザーが存在するイメージです。GCP というか Google の場合、アカウントというとユーザーのイメージでユーザーアカウント、特権管理者アカウントと言ったりします。以下、混乱しそうなので、GCP の場合もユーザーと記述しています。
ルートユーザー
AWS を新規で使用する場合、最初にルートユーザーが作成されます。GCP ではルートユーザーは存在しません。GCP プロジェクトではオーナーが管理者権限と言えます。また、G Suite(現 Google Workplace) や Cloud Identity を使い組織管理する場合は特権管理者というユーザーが存在しますが、ルートユーザーとは違い GCP のユーザーを管理する組織の管理者となります。
AWS のルートユーザーは全権限を持っているためそのまま使うことができますが、業務ではルートユーザーは使わず、IAM で管理者権限など必要な権限を付与したユーザーを作成して使います。（案件では通常ルートユーザーの権限を貰えることはありませんが・・・）
AWS の IAM セキュリティのベストプラクティスについて、公式ドキュメントに記載があります。ちなみに GCP も特権管理者の管理にベストプラクティスがあります。
プロジェクトがない
GCP はプロジェクト単位にサービスを作成、開発、運用します。ですので、コンソールに入るとプロジェクトの画面となります（組織の時もありますけど）。プロジェクト単位に本番環境、ステージング環境、開発環境と分けることができてわかりやすいです。
AWS の場合、環境を分けるにはどうするんでしょうか。
環境はタグで分けたり、AWS アカウント自体を分けたりするそうです。
リージョン
AWS にログインすると、コンソール画面はリージョン単位で表示されます。
右上のリージョンを選択してリージョンを切り替えます。
マルチリージョンの環境構築は、いちいち画面を切り替えるのがめんどくさいなあと思いましたが、そんなにマルチリージョンの環境は作らないのでしょうか。マルチAZまでですかね。一応、コンソール画面を貼っておきます。
GCP コンソール画面
AWS コンソール画面
VPC
VPC は GCPと AWS は名前も同じだしあまり違いがないと思いきや、大きな違いがあります。
AWSは VPCで利用する CIDR ブロックを設定する必要があります。GCPでは VPCの CIDR なんて気にしたことはありません。
GCP でVPCを作成する時は、同時にサブネットも作成します。サブネット作成時にIPアドレス範囲を設定します。
AWS の VPC 作成画面
GCP の VPC ネットワーク作成画面
サブネット
GCP は １つの VPC 内には複数リージョンのサブネットを作成できますが、AWS は１つの VPC には１つのリージョンのみ設定が可能です、というか、そもそもリージョン毎の画面なので、他のリージョンを選べません。
VPC で設定した CIDR の範囲内でIPアドレス範囲を設定し、サブネットを作成することになります。
AWS のサブネット作成画面
GCP の VPC ネットワーク画面（サブネットを確認）
インターネットゲートウェイ、ルートテーブルの作成
AWS はサブネットを作成した時点では、サブネットからインターネットに接続できません。VPC とサブネットを作成してからサブネット内にVMインスタンス（EC2)を作成しても、外（インターネット）に繋がらないのです。外部IPアドレスを割り振っても繋がりません。GCPの場合、VMインスタンス（EC2)を作成した時点で外には繋がります（Default のVPCのまま、インスタンス作成時に「http、httpsトラフィックを許可する」をチェックした場合）。GCP ではルートテーブルの作成は自動でされます。AWSは自分でインターネットゲートウェイの作成とルートテーブルの設定をする必要があります。
インターネットゲートウェイの作成
インターネットゲートウェイを作成します。
インターネットゲートウェイは、VPC にアタッチする必要があります。
アタッチして完了です。
ルートテーブルの関連付け
ルートテーブルは VPC 作成時に自動で１つ作成されてますが、サブネットに関連付けはされてません。自分で関連付けます。
ルートテーブル画面
そしてインターネットに接続したい場合は、インターネットゲートウェイにルーティングする設定を追加します。以下の設定でローカル以外はインターネットにルーティングされます。
ルートの編集画面
GCPではインターネットゲートウェイを自分で作成する必要はありませんし、ルートテーブルはプロジェクト作成時に自動でデフォルトが作成されます。自動で作成されてしまうことは意識しておくべきです。
ネットワーク ACL、セキュリティグループ
セキュリティグループはファイアウォールルールと同じと思ってましたが、どちらかと言うとネットワーク ACL が GCP のファイアウォールルールに近いとおもいました。
GCP のファイアウォールルールは VPC に対しての制御ですが、AWS のネットワーク ACL はサブネットに割り当てます。複数のサブネットに１つのネットワーク ACLを割り当てることもできます。
AWS のセキュリティグループは、インスタンスなどに割り当てるファイアウォールみたいなものでしょうか。EC2 インスタンスなどに紐付けます。VPC やサブネットレベルで制御するものではありません。
設定できるのは、インバウンドとアウトバウンドのネットワークトラフィックの許可・拒否ですので同じ感じです。
勝手なイメージ図を作ってみました。
AWS のセキュリティグループは他のセキュリティグループを設定できます。これは面白いです。
例えば、kinesis Data Analytics から Elasticache にアクセスするために、kinesis Data Analytics のセキュリティグループを Elasticache のセキュリティグループに登録し許可するといった使い方ができます。
関連付け
AWS では、サブネット、ルートテーブル、ネットワーク ACL、セキュリティグループなどサービス間の関連付けが必要なものがあります。
例えば、ネットワーク ACL を作成したら、サブネットに関連付けます。
VPC を作成した段階で、デフォルトのネットワーク ACL、セキュリティグループが作成され、サブネットを作成すると、デフォルトのネットワーク ACL が関連付けられます。追加で作成した場合は関連付けが必要のようです。
GCP で関連付けするサービスは何かありましたかね。Cloud VPN と Cloud Router みたいな感じでしょうか。
VM インスタンスの鍵
AWS の VM インスタンスはみなさんご存知 EC2 です。
EC2 を作成する手順のイメージは GCP とあまり変わらないのでは？と思っていました。EC2の作成を進めていくと画面の遷移が多く、GCPには無い「セキュリティグループを新規作成、または既存のグループに割り当て」が必要です。
AWS のEC2作成時のセキュリティグループの設定画面
また、EC2 の作成の最後に以下の画面が表示されます。
インスタンスにSSH接続するためのキーペアを作成、秘密鍵をダウンロードする必要があります。（キーペアのダウンロードと書いてありますけど、実際は秘密鍵だけです。）
EC2 は秘密鍵を取得し、SSH接続で使用します。ダウンロードした秘密鍵を適切な権限(400)に変更します。
GCP の場合、SSH 接続は複数の方法があります。コンソールの VM インスタンス一覧画面で、SSH ボタンをクリックすれば特に鍵を意識せずに SSH 接続が可能です。
ローカル PC のコンソールや Cloud Shell から SSH 接続する場合も通常は鍵を意識する必要はありません。しかし鍵が無い訳ではなく、"gcloud compute ssh" コマンドで初めてインスタンスに接続する際、勝手にキーペアを作成してssh接続できるようにしてくれます。~/.sshフォルダの中にキーペアが作成されます。
GCP の VMインスタンス画面（Compute Engine の画面)
ローカル PC(Mac)から gcloud compute ssh 接続
EC2 の IP アドレス
GCP の Compute Engine を作成ではデフォルトでパブリックIPアドレスが割り当てられます。EC2 はデフォルトではパブリック IP アドレスが割り当てられません。EC2はデフォルトはパブリック IP 無効（厳密には「サブネット設定を使用(無効)」）です。パブリック IP アドレスは、インスタンス作成後に設定できます。また、 固定のパブリック IP アドレスを割り当てる ElasticIP も設定できます。
GCP と AWS の VM インスタンスの IP アドレス設定は、微妙に違うので対比表を作成しました。
IPアドレス対比表
| IP種類 | GCP | AWS | 設定 |
|---|---|---|---|
| 可変外部IP | エフェメラル | 自動割り当てパブリック IP | GCPは作成後起動中可能、AWSは不可能 |
| 固定外部IP | 外部IPアドレス | ElasticIP | 両方作成後起動中可能 |
| 固定内部IP | 静的内部 IP アドレス | プライベートIP | GCPは作成後起動中可能,AWSは作成時のみ指定可能(※) |
※ AWSの場合、インスタンス作成後のプライベートIP指定は、セカンダリIPとなる。
ローカル PC(Mac)から AWS の SSH 接続
セキュリティグループにport:22を通す設定をしてから ssh コマンドを実行します。
クラウドストレージのバケットの作成
AWS にはクラウドストレージサービスとして有名な S3 があります。GCP は Google Cloud Storage(GCS)です。クラウドストレージとしては大差ないという印象でしたが、S3 でバケット内のファイルを更新したりした時に違いがありました。
S3 の上書きの PUT および DELETE は結果整合性
S3 の管理は結果整合性のため、バケットのファイルを上書きアップロード、削除では直後に反映されない時があります。
GCS は強整合性
GCS は裏で管理に Cloud Spanner を使用しています。
この Cloud Spanner は公式ドキュメントには
水平スケーリングが可能であり、低レイテンシでのデータ配信を可能にしつつトランザクションの整合性を維持しており、可用性は業界トップクラスの 99.999% を実現します。
と記載がある通り、CAP定理を無視したデータベースです。
GCS を使っていた時は当たり前というか何も考えたこともなかったバケット内のファイル更新後すぐに反映されることは、GCP だからできていたということですね。
タグ
GCP でタグというと、ファイアウォールルールをタグで適用したりというぐらいしか浮かびませんが、AWSにおいてタグは重要で、以下のようなことができます。
- リソース整理
- タグ別にリソースを設定して、検索やフィルタリングが可能。
- コスト配分
- AWS のコストをタグ別に分類できる。
- オートメーション
- 自動タスクの制御する対象リソースを特定する。
- アクセス制御
- IAM ポリシーで、タグベースの条件を設定できる。
AWS のタグは素晴らしいです。
ARN
AWS でちょくちょく出てくる ARN ってなんだろうと思っていましたが、Amazon Resource Name の略で、IAM ポリシーや API を呼ぶときに、AWS リソースを一意に識別するものです。
サービス間の連携
GCP では Compute Engine や App Engine 、Cloud Functions から他のリソースを操作したい場合、それぞれのリソースにはサービスアカウントが割り当たっていて（別途作成も可能）、サービスアカウントに権限を付与し、他の操作を可能にします。
AWS ではサービスアカウントはなく、IAM ポリシーで権限設定をします。そのIAM ポリシーをリソースにアタッチすることで、他のリソースを操作することができます。
AWS の IAM ポリシーは、細かな権限設定が可能です。最近は GCP も Cloud IAM Conditions という細かい制御が可能なサービスがありますが、設定可能なリソースが限定されています。
暖機申請
AWS の運用業務では暖機申請という言葉を聞きます。暖機申請は、EC2 がスケールアウトする Load Balancer + EC2 の環境で、多量のアクセスが見込まれる場合、事前に EC2 をスケールさせておくために AWS へお願いする申請とのことです。
GCP ではこのような申請は聞いたことがありません。
オートスケール
GCP のような素早いオートスケールはAWSではしないようです。Kinesis Data Analytics のオートスケールは思ってスケールと違いましたので、もし使う場合はしっかり検証すべきです。
CPUクレジット
AWS の EC2 インスタンスや EKS のノードなどのインスタンスタイプを選択する際、選択するインスタンスタイプによって、CPUクレジットというものが適用されます。CPU クレジットはパフォーマンスに影響するため、単純にt系のインスタンスタイプを選定しないようにしましょう。
終わりに
ご存知の方は多いと思いますが、GCP と AWS の似ているサービスでも詳細は違いがかなりあるということがわかりました。これは AWS と GCP の思想の違いが見えて面白いところでもあります。
また、AWS案件では、GCP 案件では聞いたことがない言葉がいくつかありました。
また、インフラ設計をするときの考慮点について、大きな違いはないと思ってましたが、サービスのリソース配置・設定など細かい点はかなり違いました。私は最初戸惑いました。
本記事ではほんの一部しか取り上げていませんし、まだたくさんのサービスがあり、また日々アップデートされていますし、新機能、新サービスも毎年のようにリリースされていますので、この仕事をしている間は戸惑いが無くなることはないのだろうと思いました。
本記事ではほんの一部のみ取り上げていますが、機会があれば他のサービスも書きたい思いです。（機会があれば）
お断り
- 本記事での GCP エンジニアは、業務で Google Cloud Platform の案件に対応できるスキルを持っているエンジニアのことを指しています。
- AWS 開発案件初心者で、勘違いしている点もありえるので、もしあったらご指摘ください。