クラウドサービスについて学ぼう この記事における画像は全て ChatGPT (DALL·E 3) によって生成されています。

はじめにまとめ

  • 身銭を切り、リスクを取る
  • より多く打席に立つ
  • 自分の盆栽を持つ

この記事のスコープ

  • コンピュータサイエンスの基本的な知識（OS・ハードウェア等）はクラウド時代においても重要ですし、陳腐化の遅いより本質的な知識といえますが、それらの話はしません
  • 今回は、クラウドサービスの固有知識のような、「知ってるか知らないか」だけのあまり本質的ではないが、身につけることで短期的な生産性につながる知識をいかに得るか、という話です

何故クラウドサービスの知識獲得が重要か

  • 各種クラウドサービスの使い方のような知識は変化が大きく、陳腐化の早い知識です
  • 逆に、それらに長い時間をかけて学ぶことは無駄であり、じっくりとした学習はより陳腐化の遅い分野に使いたいものです
    • → 効率よくクラウドサービスについて学ぼう

私について

  • 前職には Rails とかフロントエンドとかをやる Web Engineer として入社して、クラウドの利用経験はほとんどありませんでした
    • 強いていえばさくらVPSを借りていた
  • 後に色々あって SRE チームに異動して AWS をはじめとしたクラウドサービスについて学ぶ必要が出た
  • 学んでみると Web Engineer にもクラウドサービスの知識は必要だし、それを効率よく得るための方法論はあるなと思った

身銭を切り、リスクをとる

クラウド散財ボーイ クラウド散財ボーイ

クラウドに身銭を切る

  • クラウドサービスの多くは従量課金や月額課金となっており、無料で試せるOSSソフトウェアとは異なり、お金を払わないと利用できません
  • 例えばChatGPTなどはお金を払っていることでより最新のサービスにアクセスできます。これらにアクセスできるようになっておくことは、学習へのハードルを下げます

クラウド破産のリスク

GitHubにpushしたIAM keyでEC2勝手に作られてビットコインマイニングされまくって有り金以上に溶かしまくった顔 GitHubにpushしたIAM keyでEC2勝手に作られてビットコインマイニングされまくって有り金以上に溶かしまくった顔

  • クラウドサービスと契約する場合、料金モデルについての理解が不足していたり、セキュリティ上の問題があると、クラウド破産のリスクもあります
  • そのようなリスクがあるからこそ、問題が起きないように本気で調べることにつながります
    • 基本的なセキュリティに気をつける
      • APIキーをGitHubにpushしない
      • パスワードは安全なものを設定し、使いまわさない
      • SSO等の、より安全な認証方式が使えるならそちらを使う
      • AWS に関しては Classmethod さんが「AWSアカウントで最初にやるべきこと」というシリーズの記事を出しているので、最新のものを参照すると良いです
    • サービスの料金モデルについては理解した上で使う
    • 料金アラートが設定できるならちゃんとする (AWS Budgets等)

会社の支援は?

  • 会社によっては学習のための制度が用意されており、申請をすることでクラウドサービスへの料金を払ってくれることもあります
  • しかし、通常は一定の条件が科されており、申請の手間もかかるため、自分が真に学びたいと思える技術には身銭を切る方が素早く着手できるでしょう
    • やりたいことはやりたいと思った時にやろう

より多く打席に立つ

試行錯誤のサイクル

  • ソフトウェア開発は失敗のコストが低い、または低く抑えることが可能な分野であり、多くの試行錯誤のサイクルを回すことで成功確率が上がります
  • この原則をクラウドサービスの学習にも当てはめ、まずは何でもいいので使ってみることが重要です
  • 次に、状況に応じて適切なレイヤー・サイズ感で試行錯誤を繰り返すことを意識し、そのための選択肢を持っておくことが重要です
    • CIで自動テストを実行する環境を持っていても、すでにコケるテストがわかってるならそこだけ手元で実行する、みたいな話

サンドボックス環境の活用

サンドボックスでハッキングに興じる サンドボックスでハッキングに興じる

  • リアルなサービスやウェブサイトを運用している人であれば、壊れても困らない別の環境を持っておくと便利です
  • AWSであればAccount、Google CloudであればProject、GitHubであればRepositoryといった具合に、作って壊して学びましょう
  • とりあえずWeb UIからポチポチやって、そのサービスを構成する概念や機能等を把握していきましょう

Infrastructure as Code (IaC) ツールの活用

  • サービスによってはサーバーの起動時間に応じて課金されるものがあり、Terraformなどのツールを使えば、インフラを必要な時に作成し、不要になったら削除することでコストを最小限に抑えつつ学習に利用できます
    • 例) terraform apply で作ったクラウドリソースを terraform destroy で削除する
  • ゲームのセーブポイントのように、学習の進捗を保存し、次の学習のタイミングで再利用できます
  • さらに、IaC ツールの CI/CD パイプラインの構築は最初は必須ではありませんが、作れるとさらに便利であり、それ自体が良い学びの機会にもなります

Web UI ポチポチ vs IaC ツール

  • 原則として、Web UIポチポチでサービスの雰囲気を理解してから IaC 化にチャレンジしましょう
  • イメージができていないものをいきなり IaC 化するのは地獄
  • イメージができた後であれば、IaC 化することでそのサービスに存在するパラメータを細かく知ることができる

自分の盆栽を持つ

盆栽としてのソフトウェアプロジェクト 盆栽としてのソフトウェアプロジェクト

盆栽とは

  • 実用的なもの・大きいものでなくて良いので、日々少しずつメンテナンスしていくソフトウェア
  • 自分の盆栽としてのソフトウェアやウェブサイトを持つことで、自然とクラウドサービスの利用環境を作り、学習を続ける動機を保ちます
  • 現代の開発・メンテナンスにはクラウドサービスの利用がほぼ必須となっており、盆栽の作成・運用することで知識を深めることができます

おすすめの題材

  • ウェブサイトの自動デプロイ: 自分のウェブサイトを GitHub で管理し、PaaS 等に自動デプロイするように設定。例えば、S3 + CloudFront の構成に挑戦するなど
  • 独自ドメインの管理: 自分の所有する独自ドメインを Terraform で管理し、ドメイン関連の設定をコード化
  • CI/CD パイプラインの整備: 自分用のツールを作成し、GitHub Actions で CI/CD パイプラインを設定
  • Web アプリケーションの作成: AWS Lambda を利用してシンプルな Web アプリを作成。例えば、好きなアーティストのサイトをスクレイピングしてRSS化し、RSSリーダーやSlackに読ませるアプリケーション
  • 会社のインフラ的な人たちがセットアップしてくれた仕組みを自分でも真似てみる
    • 当時在籍していた会社にあった仕組みを真似て、Route53 の管理には roadworker、IAM の管理には miam を使っていたことがありました。 (現在は全て Terraform に移行)
    • 働くように遊び、遊ぶように働く

おまけ

技術選定について

  • 大きく分けて2つ
    • 富豪的に、本来必要ない規模感のソリューションを敢えて使ってみる
      • 業務では正当化されづらい、ある種の贅沢
      • 趣味の規模感には合わなくとも、いずれ本業で役に立つかも
    • 規模感に合わせて、適切なソリューションを選択する
      • 技術選定への審美眼みたいなものが養われる
      • 財布にも優しい

投資戦略

  • 趣味の活動にどれだけお金を使えるか、は人や状況によっても様々
  • それでも、ある程度身銭を切って学んだことは将来のメシの種になるはず
  • 自分が自由に使えるお金のうち、あらかじめどれぐらいはクラウドサービス類に使う・使えるのか決めておくと良いかも
    • 自分は毎月手取り収入の 1.5% ほどを各種クラウドサービスに使うことにしています

敢えてのダメ出し: 企業において、個々人が自ら身銭を切って学ぶことを期待するのは良いことか?

  • 経営陣だったりマネージャーだったりの立場で「身銭を切れ」みたいな主張をしてしまうと反発は大きそう
  • これはあくまでも、「企業から切り離された個人としての成長戦略」の話
  • 組織が拡大してくると、全員バラバラにこういう期待をしても非効率なので、ちゃんと育成のための体制を整える必要が出てくる
    • それはそれとして、個人はそんなのあってもなくても自分に必要なこと・学びたいことを学ぼう、というのは矛盾しない