Yamashita

## AWSインフラ設計/構築 BtoC向け巨大質問サイトにおいて、オンプレからAWSへの部分移行を担当。 AWSインフラの設計、AWS請求代行パートナーの選定/調整や、オンプレとAWSの専用線敷設なども実施しました。 10年以上前のシステムをクラウドネイティブに移行すべく、積極的にLambdaなどのサーバーレスアーキテクチャなどを提案し、必要に応じて最適化が行えています。 システムに関してはクラウドネイティブで設計し、全てコンテナで構築を行い、ECSやその他AWSサービスをTerraformで構築し、IaCを実践しています。 新人のOJTも担当しており、IaCの基本的な概念やAWSに関する実践的なトレーニングも行っています。 ## マネージメント ### 組織構造 2019/7からSREグループとしてグループが独立し、部門長として上記プロダクトの他に2プロダクト(BtoB / BtoC) を運用するチーム(計7人)をマネージメントしています。 1つのプロダクトにはリーダーを最低1人、メンバーを2人アサインし、メンバーの技術的な成長を促進するとともに、リーダーのピープルマネージメント/プロジェクトマネジメント能力の向上を図るべく、このチーム構成を提案し、実現しています。 予算策定/計画策定なども、責任者としてプロダクトサイドや開発部、経営陣などと調整/交渉を行いつつ、適宜スキルトランスファーを行い、各リーダーに権限委任をして属人化の排除やリーダークラスのスキル向上を図っております。 また半期に一度の評価などを実施し、また評価制度の改善案を提案するなどを行いました。 ### 旧来のDev vs Ops の改革 アプリケーション(PHP/Java)のコードは開発、それ以外のミドルウェアやインフラはインフラのチーム、という構造となっており、インフラと開発で完全に分断されておりました。 その結果、開発は新しいものを早く作る、インフラは今あるものを守るというミッションにこだわり過ぎてしまっていたため、プロダクトの成長が遅くなっていると感じました。 そのため、開発にもAWSを触る機会を提供しつつ、インフラ側も積極的に開発のコードを読み、気になったところを聞ける文化を醸成し、現在では開発がインフラのTerraformにPullRequestしたり、インフラが開発のPHPに対してPullRequestする文化が作られました。 また、プロダクトのSLI/SLOの策定がされないまま運用が進んでいるプロダクトに関しては、開発/企画/営業などとともに、SLI/SLOとはなにか、どのようにプロダクトに活用するかを説明し、策定を行いました。 結果、指標やエラーバジェットを決めたことで極端にリリースを恐れなくなり、プロダクトのリリースサイクルやリリース時間が短縮できました。 ### 積極的な技術のIn/Outを促す グループ/本部の中で定期的にLTを行う文化を作り、小さなことでも周囲にアピールできる場を作りました。 また、勉強会なども原則的に自由に参加してもらい、自分自身も率先して参加して共有を行うなどをしております。 その結果、技術的に興味を持って検証した内容や、トラブル/ハマったポイントなどを周りに共有する文化ができ、各プロダクトでその結果を参考にすることで、トラブルやバグなどが以前より低減されています。

AWS での新規インフラ環境構築やオンプレミス環境の運用/保守、各種障害対 応など、縁の下の力持ちという立ち位置で業務を遂行。 また、正社員/業務委託の採用面接なども実施。 ◆ au 系サービスのインフラ設計/構築 (オンプレミス) au スマートパス(会員数約 1,500 万人)のシステムリプレースに伴い、インフ ラ環境の刷新にあたり、構築開始当初は統一されていなかった Ansible や Serverspec のコーディング規約などを決め、Github を使用しチーム開発を実 施。 開発チームとの調整なども行い、最適なインフラを構築することができた。 ◆ au 系サービスのインフラ設計/構築 (AWS) ポイント貯める(90 万 PV/day)、au 占いなど(40 万 PV/day)などのアクセス数 が多いシステムのインフラ保守/改修などを担当。 アクセス数が多いため、障害になるポイントを一つずつ改善していき、突発的 な高負荷にも耐える事ができる構成となった。 EC2/RDS/Elasti cache Lambda CloudFormation CloudFront CodeDeploy ECS DynamoDB Ansible terraform Serverspec Capistrano Python Ruby PHP ◆ 自社メディアシステムのインフラ設計/構築 (AWS) リリースのスピードが優先されるシステムに関しての構築も実施。 AWS の構成テンプレートを作成し、スピーディーに構築が完了できるよう下地 を作った。 また、デプロイの仕組みなども各プロダクトに合わせ開発を実施。 ◆ チームリーディング(社員: 4 人 パートナー: 4 人) 各プロジェクトを担当する他に部内の業務に関しての推進を実施。 100 以上ある AWS アカウントの監査ログを取得するツールや、AWS のコスト管 理(RI や SpotInstance 導入)、またルール化されておらず不明瞭だった事項に 関しても、チーム内で議論を重ねルールを策定。 また、各メンバーの担当業務のフォローや教育/指導、開発部/バックオフィス との折衝なども実施。

◆ ASP サービス運用・保守 ASP サービスである OKBiz の運用を担当。 サーバラッキング~構築、運用や障害対応、アプリケーションバグ調査やベン チマーク、新技術検証などを実施。 ◆ クラスタリングソフトウェアの移行 従来の冗長化方式である Heartbeat から Pacemaker への移行を行う。 Heartbeat の場合、稀にクラスタの切り替わりに失敗し障害時間を伸ばしてし まうことがあったが、Pacemaker への移行を行い確実に切り替わるクラスタを 構築することができた。 ◆ サーバ構成管理ツールの導入 サーバ構築時の工数削減のため、解決策を検討。 検討した結果 Chef を提案し導入することができ、従来 3 日以上かかっていた サーバの構築を 1 日以下に短縮することができた。 また、構築漏れやミスを発見するために ServerSpec を導入。 以来、構築時の確認も自動化することができた。 ◆ 監視環境改善 サーバの老朽化に伴い、ハングアップが発生するサーバが多発した。 そのため、IPMI と Zabbix を使用しハングアップが発生した際に自動で再起動 を行う仕組みを構築。 以後、障害時間の短縮を行えている。 ◆ Ruby on Rails アプリケーションサーバ移行 Apache+Passenger で動作しているアプリケーションのパフォーマンスが悪 く、定常的に負荷が高い状態であったため、Nginx+Unicorn への移行を提案し 実施。 設定の調査や入れ替え、トラブル対応なども実施。 その結果、ページレスポンスは最大 2 秒ほど高速化し、負荷も半分以上低減し たたため、現在も移行を進めている。 ◆ td-agent 導入 ログ集約ソフトウェアである td-agent の導入を実施。 集計のおいては、日次バッチでログを転送/集計していたが、td-agent の導入 によって高速化とリアルタイム化を行うことができた。

障害対応・原因調査のほか、臨時メンテナンス作業やシステム設定変更作 業、懸案管理を実施。 主に運用監視周り(JP1/Cm2/NNM)の設定変更、考案、また負荷監視ツール の作成を担当。 シェルスクリプトにて一定時間ごとに負荷情報を採取し、ログに保存する スクリプトや、一定のメッセージがログに出力された場合、アラートを出 力するスクリプトなどを作成。 また、障害対応マニュアルや、原因調査のポイントをまとめた資料を提案 し、チーム内で使用した。

PHP(Symfony)にて OpenPNE3 の開発を担当。 主にユーザから報告のあったバグの修正や、リリース前試験を行 う。 また、商用サービス用のサーバ構築や負荷試験も担当。 従来は負荷試験を行えていない状態であったが、Jmeter での負荷試 験を提案し、シナリオ作成などを行った。 また、MySQL Bench を使用した MySQL の設定パラメータチューニン グなども実施。

主に DHCP,DNS(Bind)および TFTP サーバを使用した加入者向け IP アドレ ス払い出しサーバを構築。 構築タスクの他に、手順や仕様、設定値などのドキュメントを作成。 並行して社内のサーバ構築も担当。 WindowsServer2003 と Linux を使用し、ファイルサーバおよび ActiveDirectory サーバを構築し、アカウント・マシン管理の効率化を図 る。 同時にメールサーバ(Postfix)を構築し、社員全員分のアカウントを一斉 に登録するツールを作成。 また、上記に付随するドキュメント類を作成。