入社1年ちょいの私が会社のお金をｳﾝ百万円使った訳

[Supershipグループ Advent Calendar 2020](https://qiita.com/advent-calendar/2020/supership)の12/12の記事です。

<h2>自己紹介</h2>

Supership データソリューションスタジオ(DSS)で検索事業に携わっている @namarrotte と申します。

2019新卒として入社後、バックエンドエンジニアとして1年半ほど働いています。
この記事ではここ数ヶ月で私が経験した業務について書いていきます。

<h2>SREチーム参加</h2>
きっかけは入社から一年経ち、業務にも慣れてきた頃でした。
弊社検索事業部内では複数のグループがそれぞれ案件に携わっており、そのグループを横断した[SRE](https://ja.wikipedia.org/wiki/%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0)チームが立ち上がりました。
そして、上長との1on1で自分が所属するグループ(ここでは部格よりひとつ小さいまとまり)のSRE担当としてチームに参加して欲しいことを伝えられました。
私は入社時に「フルスタックエンジニアになりたい！」と志望していたため、これは渡りに船だと参加を承諾しました。

SREチームでの最初の業務は、効率化や信頼性担保の前段階としてリソースの棚卸しでした。
開発ではAWSを使っていたため、<a href="https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/">Trusted Advisor</a>を利用し、不要リソースを削除してコスト削減を行ったり、セキュリティ上問題のあるポイント(IAMロールではなくアクセスキーを用いて接続している部分)の改善を行いました。

メインのシステムを乗せるインスタンスは<a href="https://aws.amazon.com/jp/ec2/pricing/reserved-instances/">Reserved Instances(以下RI)</a>を利用して大きめのものを運用していました。
ここで、一つ問題が発生しました。
**サービス開始当初に購入したRIの期限が1ヶ月後には切れてしまうことが分かったのです。**
サービスはまだまだ継続していく見通しのため、EC2インスタンスのリソース見直しを重点的にすることになりました。

<h2>SP/RI見積もり</h2>
見直しを進めた結果、以下のような作業が必要だということがわかりました。

- 該当RIは世代が古いものだったため、世代の新しいものへと載せ替える
- 会社としては<a href="https://aws.amazon.com/jp/savingsplans/">Savings Plans(以下SP)</a>の利用を進めていきたい方針だったため、可能な範囲でSPで購入する

また、一部のRIは割り当てされずに浮いており、またConvertibleのものだったため新しい世代のものへと交換して適用することにしました。
これまでは前払いなしで購入していたRIですが、サービス運用が安定してきたこともあり、全額前払で買うことによるコスト削減も提案しました。

さて、RIやSPを購入する際には、<a href="https://aws.amazon.com/jp/blogs/news/new-instance-size-flexibility-for-ec2-reserved-instances/">インスタンスサイズの正規化係数</a>という概念が重要になってきます。
この係数が前後で釣り合うように計算を行うことで、RIは柔軟にインスタンスに適用されます。
今回の試算では正規化係数単位での計算も行い、最終結果と比較しました。

最終的にはSREチーム内やAWSのTAM(Technical Account Manager)の方に確認してもらいつつ、

- 複数のRIを組み合わせて一種類のRIへの交換
- <a href="https://aws.amazon.com/jp/aws-cost-management/aws-cost-explorer/">Cost Explorer</a>で推奨されたSPの購入
- コスト削減のため、1年全額前払いでの購入

によって対応することにしました。

<h2>稟議</h2>
さて、そうして出た金額はタイトル通りｳﾝ百万円です。
部署の年間予算としても大きな割合を締めており、購入を行う理由付けが必要になります。

ここでポイントになるのが前払いによる割引です。
以前は前払いなしで購入していましたが、前払いを行うことでより高い割引率で購入することができます。
今回の支払いであれば、全体で約10％の割引が適用されます。

この割引額を算出し、費用削減効果として稟議に盛り込みました。
また、前払いにより発生する決済がどの時点で前払いなしの金額をカバーできるかを算出した損益分岐点試算も行いました。
これらの理由付けと準備資料により、無事稟議の承認を頂きました。
<h4>損益分岐点試算の例</h4>
![Ondemand、1年前払いなし、1年一部前払い、1年全前払い.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102527/0d8291f4-b7ad-3bac-7c1a-d3a4197c9442.png)

上記のグラフだと、Ondemandと比較して7ヶ月を過ぎた時点から1年全前払いの方がお得になることがわかります。

<h2>購入</h2>
AWSマネージメントコンソール上での実購入作業についても私が担当しました。
今回行ったことはRIの交換作業とCost ExplorerでのSP購入です。

<h3>RI交換</h3>
RI交換はとても単純な作業です。
交換元RIを選択し、交換先RIのインスタンス、スコープ、AZ、…で検索し、適したインスタンスを選んで交換を実行するというものです。
予め交換対象を決めておけば問題ない内容だと思います。
実作業でも特に躓くことなく交換を実行することができました。

<h3>SP購入</h3>
SP購入では少し注意する点があります。
今回購入したのはEC2 Instance Savings Plansでした。
これは、インスタンスファミリーと**時間あたりのコミットメント金額**を指定して買う方式になっています。
そのため、必要インスタンス数をタイプごとの[料金表](https://aws.amazon.com/jp/savingsplans/pricing/)と照らし合わせながら時間あたりの合計コミットメント金額を算出する必要があるのです。
今回は試算の時点で時間辺りの料金についても算出していたので、それを利用して購入を行いました。

ちなみに、コミットメント金額を入力する欄には小数点以下3桁しかないため、合計金額に多少の差が出ることにも注意です。

<h3>購入結果</h3>
RIではカバレッジ約50％だったものが97％に、SPは10％前後だったものが93％へと改善しました。
未使用だったRIについても交換の結果使用率100％になり、不要リソースの削減とコスト削減をそれぞれ達成することができました！
RI/SP周りや、稟議用の資料の書き方など様々なことを学べた業務でした。

<h2>おわりに</h2>
この記事では2年目半ばで挑戦したAWSでのSP/RI購入についてお話しました。
こんな感じで、弊社ではやりたい！という声を上げれば挑戦させてくれる環境があります。

また、弊部署では今の所私以外の新卒が居ないので、後輩に飢えています！
もし興味が湧いたな〜という方は以下リンクなど見ていただければと思います！
 【[Supership株式会社 採用サイト](https://supership.jp/recruit/)】
是非ともよろしくお願いします。