291695 ランダム
 HOME | DIARY | PROFILE 【フォローする】 【ログイン】

Rakuten Tech Blog

Rakuten Tech Blog

【毎日開催】
15記事にいいね!で1ポイント
10秒滞在
いいね! --/--
おめでとうございます!
ミッションを達成しました。
※「ポイントを獲得する」ボタンを押すと広告が表示されます。
x
2016年12月19日
XML
カテゴリ:Advent Calendar
Hello everyone! 楽天札幌支社のyokopyです
北海道札幌市に楽天の開発拠点があることはあまり知られておらず、札幌の勉強会などで自己紹介すると驚かれることが多いです。
今回は、そんな札幌支社で日々私が行なっている業務内容について紹介します。

業務の紹介

私が所属するグループの役割は、楽天内で開発されるWebサービスの運用です。

開発には様々なフェーズがあり、企画、仕様決定、開発、テスト、リリース、運用というサイクルが回っています。初期段階のサービスでは、開発~テストまでのサイクルが多く回りますが、サービスが成熟すると、運用フェーズの役割が大きくなります。
その頃になると、多くのユーザの皆様に利用されるサービスになっていますし、社内でもそのサービスの利用が当たり前になっているからです。
私たちのチームではその運用フェーズのサービスを中心に担当し、いかに少ない運用工数で安定的なサービスを数多く提供できるか、日々考え、運用しています。
楽天にはたくさんの開発チームがありますが、中でも私たちのチームが最も多くのサービスを担当しているチームだと思います。

SRE? DevOps? 今運用が注目されている!?

以前、母親に普段どんな仕事をしているか聞かれてことがあり、楽天のサービスの運用だよと答えると「運用ってなんだか地味ね」なんて言われたことがありました(苦笑
確かに、新規サービスの開発に比べると、既存サービスの運用や保守というのは地味に聞こえてしまいます。
しかし、ここ数年DevOpsやSREといったキーワードと共に運用についての注目が高くなっているように感じます。それはなぜでしょうか?
そこにはいくつかの理由があると思いますが、私個人としては、新規サービスを開発したエンジニアが運用まで一貫して行った場合、更なる機能の開発に掛ける時間が取れないこと、また運用自体に集中できない結果、バグ修正やオプティマイズがおろそかになってしまうと、サービスレベルが落ちてしまうからだと思っています。
スピーディーに機能を開発していくチーム、運用に専門家するチームが協働することで、サービスレベルも高いものになっていくのではないでしょうか。

運用が発生する例

この業界は、日々新しいベストプラクティスが共有され便利なツール、フレームワークが生まれていきます。
しかし、それを上回る勢いでWebサービスは多様化、複雑化し、求められるリリーススピードも短くなっています。
その結果、
  • ひとまず、リリースすることが第一目標
  • コードレビューも最低限バグ探し優先、適切にログを出しているかなどまで目が届かない
  • テストコードは書くけど、最初はアクセスも少なそうだし負荷試験は後回し
  • 管理画面はリリース後に頑張ります
なんてことを、経験する人も少なくないのではないでしょうか?
書いていて自分も耳が痛い話です。
開発したサービスが一旦世の中に出てしまうと、そこには責任がついて回ります。
  • リリース後に見つかったバグがあれば、最優先で修正するのはしょうがありません
  • しかし、管理画面がないせいで、ビジネスサイドから毎日のようにデータ登録依頼がきたり、経営層に報告するために、PVやUUの提出を求められたり、
  • ユーザサポートから登録したデータが登録されていないとクレームが来たのでログ調査をお願いされたり
  • 上司から急なイベントで高負荷が予想されるけど、どれくらいまで耐えられる?と質問されたり
「リリースするまでが忙しいと思って頑張ったのに、リリースした後の方が忙しいじゃねーか!?」
という状況になってしまいます。
このような状況では新機能の開発なんてできません。
そこで我々の出番です。

運用改善例

成熟し、開発が少なくなったサービスを積極的に私たちのチームに移管し、
我々は、標準化と自動化によって、開発担当チームが2日掛けて行っていた運用作業を

数時間に短縮し最終的には0にしていきます。

それによって、少ない人数でより多くのサービス運用を実現しています。
この結果、開発グループは煩わしい運用作業から開放され新規機能開発に集中できるようになります。

具体的な事例

ここまで技術的なTopicが少なかったので、具体的な事例を幾つか紹介します。
1. レガシーコードの刷新
  ruby1.8.7/rails 2.3テストコードなしのサービスを、ruby2.3/rails 4.2にver upしテストコードの整備を行う。
2.リリース改善
  手動リリースをDockerを使ったBlue Green 自動デプロイに改善
3. キャパシティ確認、障害時の挙動確認
  負荷試験を実施し、システムがどれくらいのアクセスまで耐えられるか確認。
  また、高負荷状態でDB,Cacheサーバがダウンしたらどうなるか確認。
4. 監視システム開発
  外部Cloudから、自サービスへ定期アクセスを行うことで、サーバダウンだけでなく、SLB/ネットワークダウンの検知も行う監視システムをELK スタックを使って開発。
5. 管理画面、ツールの整備、パフォーマンス改善
  管理画面やツールの整備を行うことで、エンジニアの作業を減らす。
  DBのインデックス追加などのチューニングだけで、4時間掛かっていたデータ抽出を3分に短縮。

最後にリクルーティング

北海道札幌市にいながら日本有数のトラフィックを誇る楽天のサービスに直に触れる機会があり、レガシーコードのver upやDockerを使ったデプロイ改善、様々な自動化などエンジニアのキャリア的にも恵まれた環境だと思います。
現在は、Rubyのサービスが多いですが、PHPのサービス、JSゴリゴリのサービスもあります。
早く帰れる日は、仕事帰りにみんなでボードに行ったり、休日に集まって登山に行くなんていうアクティブなこともしています。(釣りスピリッツ大会も開催しています)
みなさんからのご応募をお待ちしております
また、勉強会も行う予定ですので、そちらもお楽しみに!





お気に入りの記事を「いいね!」で応援しよう

Last updated  2016年12月19日 09時09分19秒
コメント(0) | コメントを書く
[Advent Calendar] カテゴリの最新記事


■コメント

お名前
タイトル
メッセージ
画像認証
別の画像を表示
上の画像で表示されている数字を入力して下さい。


利用規約に同意してコメントを
※コメントに関するよくある質問は、こちらをご確認ください。


PR

Calendar

Category


© Rakuten Group, Inc.