入社1年振り返り AdventCalendar@Goals(12/5)
概要
Goalsアドベントカレンダー企画12/4担当のSREの間橋（@myabao）です。
2023年2月に入社してからそろそろ1年経過しようとしているので、記憶が新しいうちに残しておこうと思います。
Goalsに入社を決めた理由などはこちら
入社月
SRE 内のAWSクラウド/インフラレイヤーを中心にみるという役割はあったものの具体的にやることは決まっていませんでした。ただ、配属部署のメンバーが手厚く開発組織の現状についてオンボーディングしてくださったおかげで課題やこれからやるべきことの見通しが良くなりました。
Infrastructure as Code
当時、GoalsのAWSインフラ環境はCloudFormationとCDKで構成されておりましたが、全てのサービスがIaC管理されているわけではなく、マネージメントコンソールやCLIで構築されているものが残存している状態だったため、まずはこれらをIaCで管理していくこと求められていました。前職でTerraformをよく触っていた、importのしやすさからTerraformを選定しました。GoalsのアーキテクチャではStep Functionsを活用していましたが、本番環境と検証環境で分かれておらず、変更しにくいというのも課題があり、それぞれ別環境にプロビジョニングすることも必要でした。ここでは概要だけに留め詳細な内容は別記事に残そうと思います。
実施リスト
既存のStep Functionsのリストを抽出
全てのStep Functionsをjsonで抽出 Shellscriptで実装
そのjsonファイルをinputとしてTerraform Step Functionsのmoduleを利用するようにtfファイルを書く
Terraform のplanで差分がでなくなるようになるまで各パラメータを調整
GitHub Actionsに組み込み 特定のブランチにマージされたら反映するようにする。
Savings PlansとReserved Instancesの提案から購入
Step Functions以外で利用しているサービスとしてはECSとRDS/Auroraを利用しておりましたが、Savings Plans/Reserved Instancesは購入しておりませんでした。先月、先々月の利用状況を鑑みてカバレッジ率が60%〜70%ほどを目指して購入計画を立て、購入方法は全額前払い、一部前払い、前払いなしとあるのでそれぞれのコスト削減額を見積もり、購入計画とどのぐらいコスト対効果があるのかをコーポレート部門に提案しました。年間契約になる、全額前払いの場合は特定月でのAWS利用料金がかなり増加する、円高が進んだ場合メリットが薄くなるといった懸念があり、どのような反応を示すのか不安でしたが、提案内容について前向きで全額前払いを選択しました。その時の弊社代表佐崎の「全額前払いでいいでしょ。どうせ使うんだし」の言葉が印象に残っていることを覚えています。なので数百万単位の購入ではありましたが、背中を押してくれた気がして臆せず購入ボタンを押せましたw 2023年11月24日時点では円安が進んでおりなおさらこの時購入してよかったなと感じております。（また購入時期が迫っているのですが。。）
もし購入しなかった場合の試算
もし購入しなかった場合の年間コスト試算してみます。購入費用は例です。
購入費用 $24,000 オンデマンドだと$36,000 と仮定
2023年 2月 時点では１ドル135円だったので 135 × 24,000 = ¥3,240,000が年間コストですが、１ドル145円と仮定すると 145 × 36,000 = ¥5,220,000
200万円ぐらい違いますね。。
セキュリティ対応
これも全て書いていると膨大な量になってしまうのでSSH制限対応をピックアップします。
踏み台サーバのSSHポートがフル開放
社内リソースへのアクセスは会社の拠点 固定IPで絞るのが一般的でしたが、コロナ禍によりリモートワークが当たり前になった影響で固定IPで絞るというのが難しくなりました。そのため、踏み台へのSSHポートの制限が難しい状況であったようです。案の定シスログを確認すると海外からのSSHポートアタックが日常的に出力されてました。
対策
ec2-userを削除する SSHポートを変更するなども検討したのですが、根本解決にはならないので、アクセス必要なメンバーは全員AWSリソースにアクセスできる権限を所持していたことからSSM Session Manager経由でのアクセスにするようにしました。DBへのアクセスはTablePlusを利用することが多いのですが、各自のローカル設定を適切にすることでローカル→（SSM）→ 踏み台→DB とできるのでSSHのルールを削除できるようになりました。ただ、一部ローカルからのSSHアクセス要件があり、その場合はVPNサーバを介すことで接続の信頼性向上を行いました。
GitHubの個人リポジトリからの組織管理リポジトリへの移行
アプリケーションを管理しているリポジトリが個人のアカウントで管理しており、企業管理への移行を行いました。GitHubを会社で利用したことがなかったので個人的にはこれが一番の難易度でした。
移行以前の状況
個人リポジトリに入社した方をコラボレーターとして招待する仕組みでしたが、リポジトリが一つしかないため、実際にアプリケーションには関係ないコードなどもそのリポジトリにある状態でした。予め個人のリポジトリとは別に会社のOrganisationは作成済みであったので、単純にVersion Control System(VCS)としての利用であれば移行は容易かったのですが、PullRequestトリガーでさまざまなイベントを発火（webhook）させており、何かおきるとデプロイができないなど影響が大きいことから慎重に進める必要がありました。とはいえ、webhookの制限にかかってきてしまった（制限:20までで緩和不可）こともあり、そこまで悠長にできない状況でもありました。
移行計画
最初は既存のリポジトリやwebhookに影響がないようにforkした後に諸々設定を行う計画を立てました。ですがこの方法だと既存PullRequestや既にマージ済みであるPullRequest上のやりとりがもっていけないため過去のやりとりを確認する場合は既存リポジトリにアクセスする、といった運用の負荷が上がってしまう懸念がありました。改めて他方法がないか調べてみるとリポジトリの移譲という方法があることがわかりました。
しかも移譲後旧URLにアクセスしてもリダイレクトしてくれるというおまけつき！じゃあこれだけをやればいいじゃん！ とはいかず、前述にある機能webhookで発火されるイベントまでは移行されないので予め発火されるイベントを先行して作成しておく必要がありました。（ここもこれだけで記事が書けそうなぐらいボリューミーなので詳細は割愛します。）移譲自体は個人リポジトリを所持している方に依頼し、移譲完了後にローカル設定を開発メンバーに周知し無事移譲作業は完了しました。
ローカル設定
git config --local remote.origin.url git@github.com:[Organization名]/[リポジトリ名].git移譲後の副次的な影響としてCopilotの導入もしやすかったです。導入時の記事はこちら
地味に大変だった移行ですが、開発メンバーにこの大変さが少しでも伝わればいいなと思い、弊社のBeerBash企画でも「GitHub 個人管理から組織管理へ」という題で社内登壇もさせていただきました。
翌年の目標
いくつかあるのでカテゴリをわけて
コスト対策
入社してからAWSコスト削減施策として100万/月はさげることはできてはいるのですが、サービスのスケールに追いつけているとはいえず、現状まだAWSコストが高めの状態です。AuroraCluster のI/O-Optimizedを有効にすることでコストが大幅に下がるのがわかってはいるのですが、バージョンアップが必要で、バージョンアップすると性能が劣化するという事象があり、まだ実施できていません。直近、実施するためにはどのようにすればいいか計画をたてているところになり、翌年実施できればと考えてます。
AWSアカウント分離
現状本番環境と他環境は一つのAWSアカウントで運用しており、AWSで検証を行いたいときなど環境が混在しているため慎重に行う必要があります。AWSもOrganizations管理としAWSアカウント単位で環境を分け、より検証がしやすい環境を整えていきたいです。
開発組織向上
弊社プロダクトのスケールに伴い開発部の組織も拡大していっています。CopilotやGatherなどツール系にとどまらず、BeerBashのような開発メンバーのエンゲージメントがあがるような施策の企画立案運用などにも積極的に介入していきたいと考えてます。
生成系AIの活用
生成系AI 大規模言語モデル（Large Language Models、LLM）を社内、プロダクトへの組み込み問わず活用していければなと考えてます。（現状どのような活用方法があるのか思案中）
Developer Experience（開発体験）をあげることもしくはそのような組織に属すことに興味ある方は以下からどうぞ！