- すべての選択について Endorse（支持）と Regret（後悔）で表示
AWS の選択
- AWS と Google Cloud の比較: AWS を選んだことを 支持。AWS は顧客重視。Google Cloud はロボットと自動化に依存しているように感じる。
- EKS: EKS の利用を 支持。EKS は AWS サービスとの深い統合を提供し、Kubernetes も多くの面で追いついてきた（
externaldns を使って Route53 と統合するなど）。
- EKS マネージドアドオン: EKS マネージドアドオンの利用を 後悔。インストールをカスタマイズする必要があり、Helm チャートに移行してからのほうが運用体験が良かった。
データベースとキャッシュ
- RDS: RDS の利用を 支持。データはインフラで最も重要な部分であり、RDS のコストを払う価値はある。
- Redis ElastiCache: Redis の利用を 支持。Redis はキャッシュ用途でも一般用途でも非常に効果的。
- ECR: quay.io から ECR へ移行したことを 支持。ECR のほうが安定しており、権限統合もより深い。
ネットワークとサポート
- AWS VPN: AWS VPN の利用を 支持。VPN は設定も理解も非常に簡単。VPN アクセス管理には Okta を使っており、とても良い体験だった。
- AWS プレミアムサポート: 後悔。AWS プレミアムサポートは非常に高価で、社内に AWS の知見が不足していないならその価値はない。
- Control Tower Account Factory for Terraform: AFT 統合を 支持。アカウント作成を自動化し、タグの標準化にも役立つ。
プロセス自動化
- Slack ボットによるポストモーテム自動化: ポストモーテムプロセスの自動化を 支持。人々にポストモーテムを書かせる後押しになる。
- PagerDuty のインシデントテンプレート利用: インシデント発生時にテンプレートを使うことを 支持。Notion の柔軟性を活かして多少のカスタマイズも可能。
- PagerDuty チケットの定期レビュー: アラート設定を定期的に見直すことを 支持。重要でないアラートも無視されないように管理できる。
- Datadog または PagerDuty でのポストモーテム管理: ポストモーテム用に統合された管理ツールを使うことを 後悔。どちらも事後プロセスのカスタマイズが難しい。Notion のような強力なツールを使うほうがよいと考えている。
その他
- 月次コスト追跡ミーティング: SaaS コストを見直す月次会議を 支持。費用が妥当かを確認し、必要な対応を取る。AWS では項目をタグ別にグループ化し、アカウント別にも区分。AWS に限らず、会社の主要な支出源をすべて確認することを勧める。
- FaaS をもっと活用しなかったこと: GPU ワークロードには FaaS の選択肢がなく、全面的には使えなかったことを 後悔。多くの CPU ワークロードは FaaS で処理できたはず。Lambda のもうひとつの隠れた利点は、高い精度でコスト追跡を非常に簡単にできること。
- GitOps: GitOps の利用を 支持。インフラの多くで GitOps を使っており、デプロイ状況を把握するためのツール開発にも投資している。
- チーム効率優先: チームの効率向上を優先することを 支持。自動化やドキュメント化に時間を投じたことを 後悔したことはない。
- 複数アプリケーションで 1 つのデータベースを共有: 複数のアプリケーションが 1 つのデータベースを共有することを 後悔。これによりさまざまな問題が発生した。
SaaS 導入
- アイデンティティプラットフォームの導入が遅れたこと: 権限付与に Google Workspace を使っていたが、Okta のようなアイデンティティソリューションをもっと早く導入すべきだったことを 後悔。Okta は統合性が高く、セキュリティやコンプライアンスの問題も解決してくれる。
- Notion: ドキュメント作成に Notion を使ったことを 支持。Notion は素晴らしい選択で、以前使っていたもの（Wiki、Google Docs、Confluence など）よりはるかに扱いやすかった。ページ整理のためのデータベースという概念も有用。
- Slack: Slack の利用を 支持。コミュニケーションの基本ツールとして効果的。
開発ツールとサービス
- JIRA から Linear への移行: JIRA ではなく Linear を使うことを 支持。JIRA は複雑すぎて重いと感じる。
- Terraform Cloud を使わないこと: Terraform Cloud のコストを正当化できず使っていないが、これは 後悔していない。Atlantis に移行し、必要な自動化は CI/CD パイプラインに追加した。
- CI/CD のための GitHub Actions: GitHub Actions の利用を ある程度支持（Endorse-ish）。マーケットプレイスのアクションや構文は使いやすい。一方で、セルフホスト型ワークフローへの対応が限定的なのが欠点。
技術選定
- Datadog: Datadog の利用を 後悔。非常に高価で、Kubernetes クラスターや AI 企業に対するコストモデルが適切でない。
- PagerDuty: PagerDuty の利用を 支持。製品は良く、価格も妥当。
- 差分ベースのスキーママイグレーション: スキーママイグレーション用ツールの利用を ある程度支持。データは重要であり、スキーママイグレーションはリスクを伴い得る。
- 開発サーバー向け Ubuntu: 開発サーバーに Ubuntu を使うことを 支持。サポートが手厚く、必要なパッケージのほとんどがそろっている。
- AppSmith: 社内エンジニア向けプロセス自動化に AppSmith を使うことを 支持。セルフホストしており、十分満足している。最初は retool を使ってより深い統合も検討したが、当時は数個の統合のためだけにその価格を正当化できなかった。
- helm: Helm v3 の利用を 支持。CRD デプロイや開発者教育に課題はあるが、Kubernetes オブジェクトのパッケージ化とデプロイには十分有用。
- ECR（OCI）内の Helm チャート: OCI リポジトリに Helm チャートを保存することを 支持。S3 とプラグインを使った以前の方法より問題が少ない。
- bazel: bazel については 確信がない。Go サービスのデプロイには大げさに感じられ、GitHub Actions のほうがより多くのエンジニアにとって使いやすい。
- OpenTelemetry を使わなかったこと: DataDog API を直接使ってメトリクスを送っていたことを 後悔。最初から OpenTelemetry を使うことを勧める。
- dependencyabot ではなく renovatebot を選択: 依存関係を最新に保つことをもっと早く考えるべきだったと 後悔。Renovatebot はカスタマイズ性が高いが、設定やデバッグは複雑。
- Kubernetes: Kubernetes の利用を 支持。長時間稼働するサービスをホスティングする手段が必要で、Kubernetes は人気があり、よく機能する。
- 自前 IP の購入: 外部パートナーと作業する際に自前の IP ブロックを購入することを 支持。外部パートナーにより大きな CIDR ブロックをホワイトリストしてもらいやすくなる。
- k8s GitOps に Flux を選択: Kubernetes 向け GitOps ツールとして Flux を選んだことを 後悔していない。デプロイ状況の理解を助けるツール開発は必要。
- ノード管理に Karpenter: EKS 利用時に Karpenter を使うことを 支持。他のオートスケーラーより信頼性が高く、コスト効率も良い。
- SealedSecrets の利用: SealedSecrets の利用を 後悔。開発者には複雑で、AWS が持つ既存のパスワードローテーション自動化も失う。
- ExternalSecrets の利用: ExternalSecrets による AWS -> Kubernetes のパスワード同期を 支持。開発者にとって理解しやすく、Terraform を使って AWS 内でパスワードを簡単に作成・更新できる。
- ExternalDNS の利用: ExternalDNS の利用を 支持。Kubernetes -> Route53 の DNS エントリを同期し、この 4 年間ほとんど問題がなかった。
- cert-manager の利用: SSL 証明書管理のために cert-manager を使うことを 支持。Let's Encrypt の証明書発行に非常に直感的で、問題もない。
- EKS 向け Bottlerocket: Bottlerocket を使った EKS クラスター運用を 後悔。ネットワーキング CSI の問題が頻繁に起き、デバッグも難しい。
- Terraform と CloudFormation の比較: Terraform を使うことを 支持。他の SaaS プロバイダーへ拡張しやすく、CloudFormation より読みやすい構文を持つ。
- コード型 IaC ソリューションを使わないこと: 後悔していない。Terraform や CloudFormation はデータファイルを使う一方、Pulumi や CDK はコードでインフラを表現する。Terraform の HCL の制約的な性質が複雑さの軽減に役立つ。
- サービスメッシュを使わないこと: 後悔していない。サービスメッシュは魅力的だが、企業はその複雑さを過小評価しがち。インフラ全般への助言は「少ないほど良い」。
- EKS Ingress 向け Nginx ロードバランサー: 後悔していない。Nginx の利用を 支持。古いが安定しており、実績のある技術。
- 社内スクリプト配布のための Homebrew: 社内スクリプト配布に Homebrew を使うことを 支持。Linux と Mac の両ユーザーにスクリプトやバイナリを配布するには十分。
- サービス向け Go: サービス開発に Go 言語を使うことを 支持。新しいエンジニアでも学びやすく、総合的に良い選択。
4件のコメント
関連して読んでおきたい過去のGeekNews記事
開発者1人の会社の方々、技術スタックは何を使っていますか？
1人技術スタートアップのアーキテクチャスタック
1人SaaSであるHealthchecks.ioの技術スタック
1人SaaS開発者のためのツールおすすめ
1人の女性ハードウェア企業の技術スタック
スタートアップを年6$で運営する
Stack on a Budget - 無料ティアベースの開発
最小限の労力でソフトウェアスタートアップを運営する
月50万ウォン($400)で80TBトラフィックと5Mページビューを処理する方法
本文もコメントも、どちらも価値のある内容ですね。
わあ……どこでもなかなか手に入らない実用的な情報ですね
Hacker Newsの意見
RDSを使う追加コストにはそれだけの価値がある
Google CloudがAWSより優れているというのは不人気な意見かもしれないが、Google Cloud Runを使うとDockerコンテナを夢のようにクラウドで実行できる。サービス名がシンプルで、AWSの複雑なサービス群より重要サービスの数も少なく、UIもより直感的だ。コミュニティ不足によるチュートリアル不足、経験豊富な人材を見つけにくいこと、サードパーティーツールが少ないことが欠点。使ってみることを勧める。
EC2 + ASGの利用はとても快適。概念的にシンプルで、イメージをASGにデプロイし、自動スケールポリシーを設定するだけ。心配することはほとんどない。一方で、k8sの利用はいつも大仕事になる。k8sを管理するために丸ごと1チーム作ることになる。k8sの何十もの概念を導入するか、あるいは「プラットフォームエンジニアリング」に人年を投じてk8sの概念を隠蔽する。k8sを「正しく」使えるようにガイドラインやSDK、各種バリデーターを提供する。それでもなお、数万行のYAMLとコードを書いてオペレーターを実装する。ときどき、k8sは侵襲的すぎるのではないかと思う。
SaaS製品についての意見
90年代/00年代の開発者がこの一覧を読んで、複雑さや用語に戸惑う様子が目に浮かぶ。
興味深い読み物ではあるが、ブログを書くほど十分に後悔している人なのかはよく分からない。
1台の巨大な$100kサーバーに戻って、すべてを1つの箱の中で動かす実験をしてみたい衝動に駆られる。
Kubernetes / EKSの基本を学ぶことには成功したが、ECSへの移行を検討している。Kubernetesは私たちのニーズに対して複雑すぎる。CloudFormationのようなもので制御しにくい。アドオンでプロビジョニングされたロードバランサーはKubernetes外部から参照しにくい。EKS FargateからCloudwatchへのロギングは、ドキュメントどおりにやっても動かないように見える。EKS EC2のようにCPU/メモリメトリクスも動作せず、ADOTが必要なようだ。ECSでは1/10の時間で環境を再構築でき、しかもすべてがうまく動いた。
この記事の書き方と内容が気に入った。一部の判断や推奨には同意しないが、そういう場合でも理由を読むのは素晴らしい。こうした似た記事がもっと公開されて、比較できるようになるといい。似た記事を書く気にさせられた。
みんなが使うキッチンシンク・データベースはよくある問題だが、何度も繰り返される。成長するとかなりの技術的負債と性能ボトルネックになる。RDSのようなマネージドDBを使えば、主要アプリごとに個別のDBクラスターを簡単に運用できる。