ブログ

クラウドエンジニアを雇いたい場合の質問と聞くべきポイント

このブログポストでは、あなたのスタートアップやスモールビジネスの助けになる経験豊富なクラウドエンジニアを採用する際のTIPSを紹介する。 ここでいう「クラウドエンジニア」とはポジションの説明や肩書ではなく、質や長所を表す言葉として使っている。 この手の人をCTOで雇うか一エンジニアとして雇うかに関係なく、その人はクラウドのアーキテクチャーを考える上で必要なスキルセットを持っていることが求められる。 ここでは、候補者の強みを評価し採用を良いものにするために、5つの核となる原則をどうやって使うか示したい。 あわせてインタビューの際に使えるサンプルの質問集と候補者から聞けそうな回答についても見ていきたい。

すべては顧客に関すること

以下では、ほとんどのスタートアップやその顧客にとって重要な以下の5つの原則を取り扱う。

• 可用性
• 拡張性・弾力性
• 性能
• 問題解決
• DevOps

可用性

なぜ可用性が顧客にとって重要か？

もしデジタルビジネスをやっているのであれば、ダウンタイムは最悪のシナリオだ。 アプリケーションが落ちている間に売上も下がれば評判も下がる。 分単位でのダウンタイムをエンジニアのKPIにすることを考えよう。 もしメトリクス上でスパイクが見え始めたら、なにか問題があるということだ。その場合はこちらの記事を参照してほしい

質問すべきこと

• どうやって失敗を設計するか？(訳注：すべてのものは必ず壊れるので予め壊れることを前提にして設計すること)
• どのくらい(9の数)の可用性まで設計できるか？
• アプリケーションの稼働時間をどのように監視するか？
• どのように自己修復型のアーキテクチャーを作るか？

注意して聞いておくべき点

「自分は防御的なアーキテクチャーを設計する」

クラウドエンジニアはどのよう失敗を設計するかについて以下のレベルで知らなければならない。アプリケーション / サーバー / アーキテクチャー(アプリ層、DB層など) / 物理データセンター

「自分の腕には99.999ってタトゥーを入れてます」

クラウドエンジニアは自分の過去の稼働率について誇りに思っているべきだ

「PagerDutyが来ても問題ない」

これはよいサインだ。それが仕事のオーナーシップを意味するからだ。 アーキテクチャーを設計し、それを運用する人を採用したいはずだ。 よいアーキテクチャーや自己回復型のスタックを設計するような人は、通知を有益な情報の喚起として考え、必要なアクションを全部のがしてしまうようなことはしない。

拡張性/弾力性

なぜ拡張性/弾力性が顧客にとって重要か？

スラッシュドット効果とは、ニュースやソーシャルメディアサイトからイケてないアーキテクチャーのサイトにリンクが貼られることで、大量のトラフィックが流れこむ状況のことだ(訳注：日本だとヤフー砲と呼ぶ)。 このような大量のトラフィックは自分の会社が切に望んでいたことだが、アーキテクチャーに拡張性がなければ、一番必要なときにクラッシュしてしまうだろう。 さらには、こういったスパイクが始まる前や終わった後には、できる限り費用を抑えるために弾力的にダウンサイズすべきだ。

質問すべきこと

• 突然のトラフィック増を扱えるようにどのようにアーキテクチャーを設計するか？
• 大規模なイベントをどのように監視し管理するか？
• 大規模なイベントを扱えるかどうかをどのようにテストするか？
• 通常時やピーク時の適切なサイズをどのように決めるか？

注意して聞いておくべき点

「ここも弾力性を持たせるし、そこにも...」

弾力性はクラウドコンピューティングがもたらす最も重要な利点の1つだ。 弾力性とは、できるかぎり実際のニーズとキャパシティを近づけることだ。 アーキテクチャーにおいて、全部の要素が弾力性を持てるとは限らないが、 アーキテクトは弾力性の重要さを認識し、常にその利点を追求すべきだ。

「垂直スケーリングよりも水平スケーリング」

現在のクラウドでは、既存のサーバにCPUやネットワークやストレージを追加する(垂直スケーリング)のにリスクはない。 しかし、最終的には性能とコストの制約がある。 オートスケーリンググループに小さなインスタンスを追加したりそこから外してトラフィックをロードバランスするのが、拡張性・費用・弾力性の観点からは望ましい。 アーキテクトは、意識することなく最初から水平にスケールできるようにアーキテクティングしたいと考えるべきだ。

「インターネット上のスケールサービス」

AWSには暗黙的にスケールする多くのサービスがある。たとえばAmazon S3、Amazon DynamoDBやElastic Load Balancingなどだ。 これが意味するのは、数ギガバイトを扱う状況から数ペタバイトを扱う状況にスケールしたときに、(たとえあったとしても)ほとんど手作業がないことを意味する

性能

なぜ性能が顧客にとって重要か？

ページの応答時間はユーザビリティの観点で重要なメトリクスの1つだ。 アーキテクトはロードタイムのそれぞれのミリセカンドがどこで使われているか理解するためのツールをたくさん持っている。 ロードタイムは、ユーザーの物理的な場所、サーバー側の処理、ネットワーク帯域などいくつかの要因の影響を受ける。 よいアーキテクトはすべてのスタックの中からロードタイムのボトルネックを見つけ、それに優先順位をつけて、戦術的な指摘ができる。

質問すべきこと

• システムの性能をどうやって監視するか
• 監視すべきもっとも重要なメトリクスは何か？
• アプリケーションの性能がメモリやCPUやストレージの影響を受けたときのことを教えてください。それらに関してどのようにアーキテクチャを考えたか？
• 性能を向上させるためにどのようにキャッシュを使ったか？

注意して聞いておくべき点

「データのキャッシュ」

スケールしはじめると、データベースが最初に辛い箇所となる。 データベースのクエリーをMemcachedやRedisのようなキャッシュ層にオフロードすることで、アプリケーションは高速にデータの読み込みができるようになり、データベースへの要求を劇的に減らせる。 アーキテクトはキーバリューストアへのデータのキャッシュの経験を持っているべきだ。

「アセットをエッジにキャッシュする」

ページのロードタイムを減らすもっとも効果的な方法(圧縮以上だ)の1つは、画像やスタイルシートやJavaScriptのような静的なアセットをエンドユーザーに物理的に近い場所にキャッシュすることだ。コンテンツ配信ネットワーク(CDN)はかなり簡単なプロセスで、静的なコンテンツや動的なコンテンツをキャッシュできる。 アーキテクトはCDNの利用経験を持っているべきだ。

「自分はXXXやYYYというツールを使っている」

アーキテクトが現実世界のワークロードに対して責任をもっていることを示す一番の指標は、ロギングツールや監視ツールへ精通しているかどうかだ。 アーキテクトのメトリクスはパイロットの計器パネルのようなものだ。パイロットは飛行機を飛ばすためにそれを信頼しそれに頼る。

問題解決

なぜ問題解決が顧客にとって重要か？

デジタル企業における心拍数は、機能のリリースの割合によって測定できる。 顧客をつなぎとめ満足させることは、どれだけ早くバグを修正したり新機能をリリースできるかと密接に関係ある。 もしクラウドエンジニアが「まだクラスタのプロビジョニング中だ」とか「データベースの設定中だ」とか言って開発者の進捗を妨げてしまっているとしたら、 彼はチームを革新的にさせるどころかチームを遅くしてしまっていることになる。 よいクラウドエンジニアは同じ仕事をもっと簡単に終わらせるよう改善する機会を常に探している

質問すべきこと

• 過去にどんなマネージドサービスを使ったことがあるか？
• 開発のためのデータベースを準備する時間が一番短かったときはどんなときか？
• マネージドサービスをやめて自分でクラスタを管理するようにしたときの理由はなにか？

注意して聞いておくべき点

「なぜ車輪の再発明をするのか？」

会社の形態にかかわらず、一般的な技術的要求にはバックグラウンドワーカーやメール送信やモバイルプッシュなど複雑なアーキテクチャーが含まれるようになってきている。 明らかに一般的なアーキテクチャーパターンをゼロから実装する必要があると信じているようなエンジニアは避けること。

「自分でクラスタを管理したくない」

候補者が15ノードからなるクラスタを管理することにプライドを持っているのであれば、それはたぶん赤信号だ。 たぶんそのクラスタの管理がその人の主な仕事になってしまっている(それがフルタイムの仕事であることさえある) 自分のクラスタの管理は作るときと同じくらいの労力がかかる。 よいクラウドエンジニアはマネージドサービスにクラスタの詳細の管理をまかせる。 そうすることでスタック全体にわたる幅広い領域でワークロードを最適化することに集中できるようになる。

「データベース管理者は避けたい」

Amazon RDSのAuroraのようなマネージドデータベースは、従来歴史的にデータベース管理者が背負っていた複雑なオペレーションを劇的に減らしてくれる。 データベース管理の経験はワークロードにとって正しいマネージドデータベースを選択する能力よりも重要ではなくなっている。

DevOps

なぜDevOpsが顧客にとって重要か？

物理的な製品を作っている会社は物理的なサプライチェーンに注目している。 それと同じように、デジタル企業は開発と運用(DevOps)に注目すべきだ。 企業のDevOpsプロセスをプロダクトの機能を顧客にとどける責任のあるサプライチェーンと考えよう。 戦術的には、DevOpsは信頼できて繰り返し可能な方法で、コードを書き、管理し、テストし、デプロイできるよう保証することを指す。 DevOpsの流れの中での破綻や穴は、顧客にとってのダウンタイムやサービス劣化を引き起こすのは必然だ。

質問すべきこと

• 過去にどんなバージョン管理システムを使ったか？どれが好みか？それはなぜか？
• 1つのコードベースに同時にたくさんの人が関わったときのことを教えてください。そのときどのようにデプロイしたか？
• 継続的インテグレーションと継続的デプロイメントの違いは？
• 過去にどんなDevOpsのツールを使ったか？どれが好みか？それはなぜか？

注意して聞いておくべき点

「バランスが大事」

DevOpsのプロセスや技術を導入しすぎると、人々がそれに対応できない場合には、かえって遅くなることに繋がる。 クラウドエンジニアはそのバランスを認識し、企業規模、開発者の状況、成長目標などの要素に基いて適切な落とし所を見つけられるべきだ。

「Infrastructure as Code」

今日のクラウドでは、AWS CloudFormationのテンプレートやElastic Beanstalkのebextensionの設定などを使ってテキストファイルで完全な技術的アーキテクチャを定義できる。 候補者がインフラをソースコードレベルで管理することについて知的に話せるのであれば、それは進歩的で前向きなクラウドエンジニアのしるしだ。

「自分はXXXというツールが(好き|嫌い)だ」

候補者が自分の好むツールに対して強い意見をもっているのであればそれはよいしるしだ。 CIやCDのツールが(好き|嫌い)だと学んだ人は、実際にそのDevOpsの流れを歩いてきたことを意味するからだ。

まとめ

さまざまなバックグラウンドによって素晴らしいクラウドエンジニアはできあがる。 ソフトウェア開発やDevOpsの経験はうまくクラウドに変換できる。したがってクラウドのハンズオン経験が限られているからといってすぐに候補者の評価を下げてはいけない。 もし候補者がこの記事の中で触れた内容に価値があるとおもって理解できるのであれば、候補者はクラウド特有のニュアンスをすぐに身につけられる。 なにはともあれ、アーキテクチャーを全体的に見て継続的に最適化してくれる人がほしいはずなので、そういう人を頑張って探そう。

Written by Paul Underwood, Solutions Architect, Amazon Web Services