クラウドエンジニア

この領域について

中核となる能力

• 01プロバイダーアーキテクチャ

  リクエスト量、バースト性、データの重さ、レイテンシ許容度といったワークロードの実際の形に対して、コンピュートのモデル、ストレージクラス、マネージドサービスを選びます。そして、プロバイダーの抽象がアプリケーションの必要と合わなくなる地点を把握します。

• 02ネットワーク設計

  アドレス設計、サブネットとルーティングの構造、他環境へのプライベート接続、制御されたエグレス、負荷分散です。ネットワークは、ワークロードが乗ったあとで最も引き直しにくいものの一つであり、ここでの判断は他の多くより長く残ります。

• 03アイデンティティとアクセス制御

  ロール、ポリシー、信頼関係を設計し、権限が事後のレビューではなく構造として最小権限になるようにします。企業ディレクトリとのフェデレーション、保存された鍵に代わるワークロードアイデンティティ、そして複数のポリシーが適用されるときにアクセス判定がどう決まるかの理解を含みます。

• 04マネージドサービスの判断

  プロバイダーのサービスを使う場面と、コンポーネントを自分で動かす場面を見極めます。マネージドサービスは運用負荷を下げ、結合度を上げるため、判断には何が保証されるか、想定する量ではいくらかかるか、そして将来そこを離れる場合に何が要るかを含める必要があります。

• 05データの保管とライフサイクル

  アクセスパターンに合う永続ストアを選び、保持とアーカイブの方針を意図的に定め、バックアップが取得できたことではなく復元できることを検証し、フェイルオーバー時に何が失われるかを知るためにレプリケーションの意味論を十分に理解します。

• 06可用性と復旧の設計

  停止とデータ損失の許容度を明示的な目標として表し、それを満たすゾーンとリージョンの構成を設計し、障害を予行演習します。一度も実施されたことのない復旧手順は文書であり、文書は負荷のかかったシステムとは違う振る舞いをします。

• 07プロバイダーのセキュリティモデル

  転送時と保管時の暗号化、鍵の管理とローテーション、シークレットの保管、ネットワークの分離、そして設定ミスの類型をまとめて防ぐ組織全体のガードレールです。あわせて、プロバイダーの責任がどこで終わり、利用者の責任がどこから始まるかを知ることでもあります。

• 08環境の可視性

  プロバイダーのメトリクス、フローログ、監査証跡、構成履歴を、事後の問いに答えられる形にまとめます。何が変わったか、誰が変えたか、そのリソースは以前どうだったかです。標準の監視は、あらかじめ定めた問いにはよく答え、予期しない問いには弱いため、監査履歴はダッシュボードと同じくらい重要になります。

• 09コストエンジニアリング

  支出を帰属させられるようにタグ付けと配賦を整え、想定ではなく観測された負荷に合わせてサイズを適正化し、コミットメント型の契約を意図的に選び、エグレスとゾーンをまたぐ通信を設計上の入力として扱います。最大の削減は調達ではなくアーキテクチャから生まれます。

• 10移行の遂行

  移行中もシステムが使える状態を保つよう順序を組みます。依存関係の把握、データの転送と突合、戻り道を定めた切り替え、そして誰も文書化していないものを地道に洗い出す作業です。移行が失敗するのは、技術的な部分より文書化されていない部分であることのほうがはるかに多いのです。

よくあるご質問

よくあるご質問

クラウドエンジニアとDevOpsエンジニアは何が違いますか

クラウドエンジニアはプロバイダー層を専門とします。アカウントとネットワークの構造、アイデンティティの付与と評価、システムが依拠するプロバイダーのサービス、ゾーンやリージョンの障害時の挙動、そしてそれらの費用です。DevOpsエンジニアは、どんな基盤であれ既にあるものへ変更を届けることを専門とします。パイプライン、デプロイ戦略、リリースの自動化、そしてリリース後のフィードバックです。一方はシステムが何から作られているかに関わり、他方は変更がどうそこへ届くかに関わります。小さな組織では一人が兼ね、環境が大きくなると、二種類の深さは一つの職務に収まらなくなります。

クラウドエンジニアとプラットフォームエンジニアは同じですか

同じではありません。どちらもアプリケーションの下に位置するため混同されがちですが、クラウドエンジニアリングが提供するのは要件を満たす基盤そのものです。構成、権限、可用性、支出です。プラットフォームエンジニアリングが提供するのは基盤への窓口であり、自分で組み立てることもできる社内エンジニアのために作られ、彼らが実際に使うことを選ぶかどうかで評価されます。プラットフォームは通常、クラウドエンジニアリングが整えたものの上に載ります。だからこそ、筋の通っていない環境の上にプラットフォームを築くと、背後に元の問題をすべて残したまま、きれいな外観だけができあがります。

複数のクラウドプロバイダーを使うべきですか

選択として採るのはまれで、事情によってそうなることは多くあります。意図的なマルチクラウドは、組織が理解すべき面をおおよそ倍にします。二つのアイデンティティモデル、二つのネットワークモデル、二通りの障害の振る舞いです。その対価は、交渉上の立場の強化と、多くの組織が結局行使しない可搬性の選択肢です。正当化されるのは、データ所在地の規則、顧客の要請、買収、あるいは実際の規制上の義務がある場合です。プロバイダー障害を理由に正当化されることはまれです。増えた複雑さが、防ぐ以上の停止を招きがちだからです。

クラウドの認定資格はどこまでを示しますか

プロバイダーのサービスカタログを学び、部品がどう組み合わさるはずかを思い出せることを示します。それは本物の基礎であり、キャリアの初期には価値があります。一方で、持ちこたえた権限モデルを設計したことがあるか、フェイルオーバーがドキュメントと違う振る舞いをするのを見たことがあるか、想定外の課金を原因まで追跡したことがあるかは示しません。資格は判断力ではなく準備の証拠として扱い、面接の時間は判断力に使ってください。

クラウド環境のセキュリティは誰の責任ですか

プロバイダーは基盤そのものを守り、利用者は設定、アイデンティティ、ネットワークの露出、データ保護、そしてその上に構築したすべてに責任を持ちます。公になったクラウドのデータ露出のほとんどは、この線の利用者側で起きています。意図より広い権限、インターネットから到達できるストレージ、リポジトリに入った認証情報、安全であるより便利であるための既定値です。自分が使うサービスについてこの境界がどこにあるかを言えないエンジニアは、自覚のない穴を抱えていることになります。

クラウドエンジニアがいれば支出を抑えられますか

部分的には可能ですが、採用の前にその限界を理解しておく価値があります。実際の削減には通常アーキテクチャの変更が要ります。ストレージクラスと保持期間、トラフィックの経路、遊休容量のリクエスト課金型コンピュートへの移行、誰も使っていないものの撤去です。そしてそれには、対象システムを所有するチームのエンジニアリング時間が必要です。この役割をコスト関連のチケットとアクセス申請の待ち行列として置けば、毎月レポートは出ますが、ほとんど何も変わりません。帰属を可視化し、設計変更を提案できるようにすれば、根本の傾向を動かせます。

クラウドエンジニアは既存の開発チームとどのように働きますか

開発チームの増強という形では、エンジニアは御社のチームの隣ではなく、その中に加わります。御社のアーキテクチャ原則、アカウントの慣習、セキュリティ方針、スプリントの優先順位が作業を規定し、何をどの順で作るかは御社の人々が決めます。雇用に関する部分はTalent.IDが担います。雇用関係、給与支払い、従業員福利厚生、タレント管理、そして継続的な従業員関係です。