AWS Startup ブログ

Category: Database

ビズリーチ様、ECS活用アーキテクチャー大刷新についてお伺いしました

こんにちは、Startup担当事業開発の畑 浩史です。 株式会社ビズリーチでキャリトレの開発をされている外山さん、中村さん、龐さんにAWS久下とシステム刷新についてお話をお伺いしました。 外山 英幸さん(写真右) キャリトレ事業部 プロダクト開発部  部長:キャリトレ事業部の部長としてプロダクトの企画、システム運用、保守、開発や新プロダクトのアーキテクチャーを見られています。2歳になられたばかりの息子さんがかわいくてかわいくて仕方ないとのこと。趣味はお子さんと遊ぶことと、夜にAWSの勉強をすることだそうです。座右の銘は「なんとかなる、なんとかする」。 中村 恵介さん(写真左から2番目) キャリトレ事業部 プロダクト開発部:新卒でビズリーチ社に入社し、現在はテックリードとして、アプリケーションレイヤー、インフラレイヤーともにご担当。趣味はスノーボード、ボルダリング、ゲーム、プログラミングとアウトドア、インドア両面でアクティブで、現在、独身で売り出し中とのことです!座右の銘は「千思万考」。 龐 冲さん(写真右から2番目) キャリトレ事業部 プロダクト開発部:中国 雲南省ご出身で2007年に来日され、現在はインフラのトップとしてAWSの構築や運用をされています。日本語が堪能で、社内Slackでは「日本人以上に日本語が上手い」と評判だそうです。趣味はクラシックギター。座右の銘は「一期一会」。 キャリトレとはどのようなビジネスでしょうか? 20代の方向けの転職サイトで、第二新卒の方など、初めての転職の方を中心にご利用いただいております。2014年に正式ローンチし、ビズリーチの新たな事業の柱として、現在は多くの求職者の方や企業の方にご登録いただいております。今年は5月にCMも開始し、より多くのユーザーの方々に価値を提供できるサービスを目指しています。 現在、プロダクトが抱える課題は何でしょうか? サービスが短期間で急成長したため、スピード優先で矢継ぎ早にシステムを増改築してきた結果、どうしてもその場しのぎであったり、いびつな対応となった部分ができてしまいました。結果、所謂スパゲッティコード、機能間密結合となり、問題の特定が難しいことや、影響範囲が大きくなります。また、インフラ面も全てをコードで管理しているわけではないため、実際に動いているものを見てみないと分からないことや、問題発生時の調査が難しいこと、見直しが難しいといった状況があります。 課題に対して、どのような対応をされていますか? 5年経つこのタイミングで、アーキテクチャーの刷新を現在進めています。大きな方針として、 1. スケールしやすい 2. 工数を削減する(作らなくてよいものはなるべく作らない) 3. 運用負荷が軽い の3点を常に意識しています。 また、刷新の際に他クラウドの利用も検討しましたが、これまでの経験の蓄積、権限管理、監査対応、Auroraのパフォーマンス等の観点から、既存と同様にAWSで再構築することに決めました。その際に、AWSのトレンド、王道を最大限に活用して構築していくことも方針の1つとしました。 それ以外に、Dockerコンテナ技術を使うという全社方針があったため、キャリトレもそれに沿った開発をすることにしました。その際の選択肢としてKubernetes on EC2がありましたが、Kubernetes は機能的に充実している面はあるものの、折角AWSを利用しているのに自分たちで管理することが増えすぎる点、またKubernetes をアプリエンジニアに覚えてもらう必要がある点、他のAWSのサービスとの連携による恩恵を受けられない等から、運用のしやすさを考え選択しませんでした。EKSは東京リージョンのローンチがまだなので、見送りました。結果、ECSで再構築を進めています。Fargateは構成自体を自動化して運用コストを下げるために有効なため、検証を続けています。 具体的な再構築の内容を教えていただけますでしょうか? これまで、Jenkinsでビルドしていたものを、AWS CodeBuild、CodeDeploy、CodePipelineを使って全て構築するようにしています。並列でいくつか動かしてもスケールできるように、Jenkinsを管理しないことでできるだけ運用負荷を下げることを目指しています。これまでテストに時間がかかったり、タスクを増やすと落ちたりしていたことが無くなることを期待しています。 次に認証周りについて、インフラだけではなくアプリも見直しています。ログインに関する機能をAmazon Cognitoを使うことで自前で作らないようにすることや、API GW利用によりエンドポイントの認証をSTSで行うことやロールベースのアクセスコントロールなどで工数削減に繋げています。 DBは、MySQL5.6 RDSから Auroraへ移行し、移行コストがかからず楽に移行できています。Auroraに移行することで、Slaveに対しての遅延が少なくなり、Read系の考慮点も減らすことができ、可用性の面でのメリットが大きいです。また、カラム追加のロックがかからないことやリードレプリカアクセスにロードバランサー機能があることも運用負荷軽減となります。検索については、EC2 Solrの構成でしたが、保守コストがかかっていたため、運用コスト優先でElasticsearchを選択し、専用のサーバーを立てることを減らしています。ログ周りはfluentdでエージェントを立ててEC2のサーバーを立てていましたが、CloudWatch Logs Agent-> Kinesis -> Lambda -> S3で再構築し、Athena、EMR、Glacer 、Datadogの利用を考えています。バッチはAWS Step Functionsを活用します。 今後のチャレンジは? キャリトレが大きくなるとマイクロサービス化が必要になると考えていますので、サービスを増やした時の共通基盤の作成は今後の課題です。また、将来的にはサーバレスな構成も考えていきたいです。 今回のre:Inventの新機能発表で注目は何でしたか? […]

Read More

なぜ次々と新しいサービスを出せるのか?「ミンカブ」の開発はスピード&保守性が肝!

こんにちは、Startup担当事業開発の浜宮 真輔です。 株式会社ミンカブ・ジ・インフォノイド(以下:ミンカブ)で部長を担当されている川端さんにお話しを伺いました。普段、投資をされない方でも「みんかぶ」という名前は聞いたことがあるのではないでしょうか?ミンカブはAIを活用したコンテンツ自動生成の仕組みを導入した投資家向け情報メディアの「みんなの株式」を運営されています。そちらの愛称が「みんかぶ」です。さらに、「株探」や「みんなの仮想通貨」、「みんかぶFX」等、多くの金融商品を対象としたサービスを提供し、投資を行う方々のインフラのようになっています。今回は、多くのサービスを世に生み出し、発展を続ける開発の裏側を聞いてきました。 ・まずは川端さんの経歴は? 2007年7月にミンカブにジョインしました。創業は2006年なので社員ナンバーは小さい番号ですよ。大学時代の知人がCEOと一緒にミンカブを始めるところで声をかけてもらいました。それ以前は、いわゆる大きな会社のSIerで、社会人5年目にミンカブへ転職しました。当時は仕事の進め方などに窮屈さを感じており、ワクワクしながら踏み込んでいったのを覚えています。 入社時はシステムの担当ではなかったのです。最初はカスタマーサポートを担当しておりましたが、アクセス解析など担当領域が広がっていきました。そんな折に発生したリーマンショックがシステム担当になるきっかけでした。リーマンショックにより全社的なコスト削減の必要に迫られ、事業所を移転した他、人員やサーバーラックなど様々なリソースが縮小されました。そのタイミングでシステム部門に異動したのです。もちろんシステム部門も人数は減っており、そんな状態でぎっしり詰め込まれたサーバーラックを運用していた経験が、クラウドに移行した起因になっていますね。移行までに、2回ほどハードウェアごとデータセンター移転しており、とても大変でしたね。システム的には2011年あたりからKVMで仮想化を進め、2012年からAWSの利用を開始しています。 ・現状のアーキテクチャーは? 基本はオーソドックスな形にしています。一般的なWeb3層構成で、ALBやRDS、ElastiCacheなど、AWSの標準的なサービスを利用していますね。AZの冗長化や耐障害性はもちろん意識していますが、コンテナは局所的な利用に留めています。コンテナにすることでスケーリングなど恩恵があるのは分かっているのですが、開発プロセスやシステム監視、障害対応など運用面に大きく影響するので、全面的な採用を見送っています。一方で、Kinesis・Lambda・DynamoDBを組み合わせて、サーバーレスで実現している機能もあります。ティックという価格情報からリアルタイムでチャートデータを更新する機能で、即時性と可用性が強く求められるためにこのような構成をとっています。 ・技術面のアピールポイントはなんでしょうか? 「速さと保守性」が強みです。ミンカブは多数のサービスを展開していますが、何か新しくビジネスを始めるとき、システムを提供する速さが非常に重要になります。しかし、それと同じくらい保守性も重要と考えていて、速く提供したはいいが、保守性が低くてはお客様のニーズに追随してサービスを改善できません。その速さと保守性をあげるために開発効率や運用効率などの「効率性」を最大限に高めるように努めています。アーキテクチャーをオーソドックスにしている点もプラスに働いています。シンプルな構成なため、メンバーの理解が早く、横展開がスムーズにいきます。この考えはメンバー選定においても重要です。プログラミングスキルが高いに越したことはないのですが、それ以上にコミュニケーション・コストがかかってしまっては全体の効率を引き下げてしまう恐れがあります。採用段階でWeb開発の経験があまり無い方でも、知識や技術に興味を持ちつつ、コミュニケーションがとれる人ならばOKです。現時点では、チームの中でやっていける人かどうかというのを大事にしており、技術に対する興味があれば現場で学んでいけると考えています。もちろん会社として、どのフェーズにいるかによって持つべき強みは変わっていくと思いますので、その時に求める人物像のスキルが今とは違ってくる可能性はおおいにあります。 ・海外企業との提携を多くされています。システム面の対応はどのように行っているのでしょうか? 海外のシステムが日本のAPIをつつくような構成にしていました。具体的には、情報ベンダーからはオンプレでしか提供されないデータをDirect Connect経由でAWS東京リージョンに集約していました。また、リードレプリカやAPIのエンドポイントをアイルランドなどの海外リージョンに作成し、海外アクセスのレイテンシ問題に対応しました。 もちろん問題もでてきます。ヨーロッパや北米では時差の問題があるため、API仕様に関するやりとりに時間がかかったり、日本時間の夜中に発生したトラブルの対応が遅れてしまったりしました。また、システムだけでなくローカライズした国や地域の文化を理解している人が必要だと学びましたね。当たり前ですけど法律も違えば、株式市場のあり方もエリアごとに違いがでてきます。そのため、コミュニケーション・レイヤーとして、システム・人・サービスなど階層化して展開を考える必要があると思っています。例えば、日本メンバーはAWSの環境構築やメディアの運用が得意なのですが、その考え方や手法を海外メンバーにシェアするなどのサポートに徹し、データの取り扱いなどきめ細かいローカライズは現地を分かっている海外メンバーが行う流れです。 ・最後に、AWSのいい点を教えてもらってもいいでしょうか? 色々クラウドサービスは触りましたが、AWSはユーザーが使いやすいように変化していると感じました。例えば毎日触るコンソールです。いつの間にかIPアドレスをコピーするボタンが、従来の操作性を損なわないように配置されていたりと、日進月歩でユーザー目線の改善が行われているように感じます。他にも、古い話かもしれませんがIAMロールがインスタンス作成後に変えられるようになったり、セキュリティグループを複数割り当てられるようになったりとか、コンソール以外でも細かく改善されています。 お気に入りの機能ですか?もともとオンプレでDNSも自前でやっていたので、AWSに安心してお任せできるRoute53がとても良いです。4台のネームサーバで十分な可用性があるので、公開用はもちろん、内部DNSも心置きなく利用できます。オンプレ時代は内部DNSまで構築する余力がなく、IPアドレス管理表とhostsでホスト名を管理していたので、その頃に比べると運用効率が大きく改善されました。あとは、RDSのおかげでMySQLの細かい運用を考えなくてもよくて楽になりましたね。オンプレ時代はスケールアップ=ハードウェアの入れ替えになってしまい、それだけで大掛かりな作業だったのがコンソールから数クリックするだけで対応できますし、フェールオーバーも任せられるので、マスター・スレーブの切り替え作業で冷や汗がでることがなくなりました。 これはお願いですが、リザーブドインスタンスの購入プロセスを見直してほしいですね。最近も高額なリザーブドインスタンスを購入したのですが、数クリックで高額決済されると思うと、購入タイミングで間違いがないかどうか不安になってしまいます。今後、安心して購入ボタンを押せるようになることを期待しています! 川端さん、お忙しいところお時間いただき有難うございました! 編集後記) 多くのサービスをスピーディーに展開する根幹には、アーキテクチャーや体制作りに対する明確なポリシーがあると気づかされました。海外展開におけるナレッジなど貴重なお話有難うございました! 関連情報) 株式会社ミンカブ・ジ・インフォノイド このブログの作者) Shinsuke Hamamiya(浜宮 真輔) ベンチャー企業を経て2005年に日本IBM入社。金融系の基幹システムにおけるプロジェクト・マネジメントに携わる。2016年に早稲田大学大学院にてMBA取得後、スタートアップ支援とオープン・イノベーションを促進するIBM BlueHubを担当。2018年よりAmazon Web Service Japan, K.K にてBusiness DevelopmentManager-startupsに着任。

Read More

新しいマッチングを世の中に届けたい。「くらしのマーケット」開発の歴史とは?

こんにちは、Startup担当事業開発の浜宮 真輔です。 みんなのマーケット株式会社でテクノロジー本部 本部長を担当されている戸澤さんにお話しを伺いました。みんなのマーケット株式会社はハウスクリーニングや引っ越し、家の修理やリフォームを始めとする生活関連の出張・訪問サービスに特化したインターネット商店街である「くらしのマーケット」を運営されています。口コミや料金の比較も可能なうえ、オンラインで予約できます。まさに痒い所に手が届くサービスです。マッチングサービスとして拡大が続くなか、起業当初からシステムを管轄してきた戸澤さんはどのように開発と運用をされてきたのでしょうか?   ・まずは戸澤さんの経歴は? 2011年1月の創立当初からみんなのマーケットと歩んできました。みんなのマーケットにジョインしたきっかけは、個人的にPythonのブログを書いており、それを見た代表からTwitterでお誘いがきたのがきっかけですね。エンジニアとしての経歴を考えると、中学生時代にまで遡ります。親は公務員でITを専門にしているわけではないのですが、Windows95を買い与えてくれて、PC上で絵を描くことや、ネットサーフィンをしたのがITに触ったきっかけです。特にネットサーフィンで「調べること」が大好きになり、Webサービスをつくって公開するブームを知りました。そしていつしか自分でも作ってみたいと思うようになり、C言語に触って挫折し、その後PerlやPHPにも触った思い出があります。 大学生になるとJavaや C++を使っていましたが、Webサービスを開発するうえでPythonだと書きやすいという感覚をもっており、技術ブログを参考に開発していましたね。例えば、TwitterのUserStream APIを使って地震のアラート配信するアプリも作りました。ただ、自分自身で起業という考えはなかったです。経営的な動きよりプロダクトをつくることが好きだったのです。こう話すと、趣味はプロダクト開発のように思われるかもしれませんが、ランニングやカメラが趣味です。中学生時代にのめり込んでいたカメラに最近またはまっています! ・みんなのマーケットの創業当時は? 2011年から2015年まではインターン含めて2名で開発をしていました。当時はコードを書く面白さを満喫していましたね。コーディングルールや運用プロセスを考えるよりも、とにかくコードを書いていました。当日の開発作業は、主にリリース時から実装していた機能改善がメインでした。例えば、ユーザーが自分のいるエリアを探しやすくするなどUXの改善です。UXの改善は実際にユーザーへの有益なインパクトがありました。ただ、最初の2~3年程度は売り上げがなかなか上がりませんでしたね。でも自分たちが作っているサービスは今の世の中にないものだし、利用者も少しずつでも伸びていたので漠然と期待感があり、不安な気持ちはなかったです。 その後、エンジニアが増えて、自分の仕事もプロダクト全体をみるようになりました。それに合わせて自分の価値観も「コードを書く面白さ」から「ユーザーの中にある課題を解決する楽しさ」に変わっていきました。実際にユーザーさんが喜んでいる声を聞いたり、KPIの数字が上がるのをみて、自分たちの解決策が当たったことを確認できると一番楽しいです。     ・現在の具体的な業務内容は? プロダクト全体をみているのですが、プロダクトマネージャー(以下、PM)は複数おり、PMに対して開発の視点から意見することが多いです。具体的には「シンプルにすること」「問題を正しく捉えること」。有益なインパクトを与えられるか検討することや、新機能を構築する前に既存機能の活用を促すこともあります。もちろん代表の浜野の意見も取り入れますし、PMから積極的に意見があがる風土は大事にしています。この風土を作るために、PM自身が課題、目的、得られるインパクトを論理的に理解し、それに加えて全体を見わたせるようになるよう意識しています。また開発リソースは有限なので、リソースを最大限に有効活用するために、事前にできるだけ深くメンバーが考えるように意識しています。そのためにもデータ分析は積極的に進めています。データはGlueからAthenaを経由したうえでRe:dashで表示しているのですが、そのアカウントは開発部門だけでなく、さまざまな部署にも渡しています。各部署内でデータ分析を行うことで課題点が可視化され、それぞれが改善していく流れが出来ています。 ・創業から現在まで、プロダクトは順調に拡張されてきたのですか? いいえ、2016年に大きなreplaceを行っています。創業当初はコードの綺麗さを後回しにしていました。しかし、エンジニアが増える段階で新しいメンバーに都度環境を説明するのが大変だったこともあり、replaceを行うと共にコーディング規約も作り、組織で動ける仕組みを整えていきました。システム面においてもマイクロサービスを導入し、組織ごとに開発が進められるようにしました。セキュリティ的にもリスク分散できるメリットもあります。もちろんシステム全体を理解するのが難しくなってきたという側面もありますね。尚、replace以降に限った話ではないですが、既存機能をより良くするためにユーザーの声をプロダクトに反映しています。具体的には、ユーザーにむけて定期的に行っている講座や、コンサルティングチームがユーザーから直接要望を拾い上げてきて、内部で検討を進めると共に、代表の浜野も俯瞰的に評価して対応を決めています。 ・技術面での特長は何でしょうか? 新しい技術を積極的に活用することです。いくつか例をあげると、エンジニアリソースが限られているのでAuroraなどマネージドサービスを使うことでプロダクト開発に注力出来るようにしています。また、マイクロサービスの中でコンテナ化できるものはECSに入れていますね。 ・AWSの良い点も聞いていいですか? AWSのプロダクトとしてはLambda が好きです。実行回数が多い割には安いし必要なときだけ実行できる点もありますが、処理の安定性を管理しなくていいことや、Cloud Watchで全て監視できる点も良いですね。 AWSを継続している理由としては、技術面やプロモーションなど手厚いサポートにあると思います。また、新しいサービスが多く出てくるので、より便利に使えるのではないかと期待があります。逆に使い切れないくらいサービスがあるので期待値を超えているかもしれませんね。 あとは、コンサルティングチームはやりとりに電話を多く使っています。Amazon Connectであれば今出来ていないLambda等でシステムと連携もでき、より活用できると期待しています。Amazon Connectが早く東京リージョンに来てくれるといいですね!(取材は2018年11月29日に実施) 戸澤さん、お忙しいところ有難うございました!               編集後記) サービスが成長していく中で、戸澤さんがプロダクトと同様に、メンバーや文化を大事にしている点、そしてメンバーや文化の話をするときの笑顔がとても印象的でした。開発されている皆さんの温かさがプロダクトにも反映されているのだと思います。Amazon Connectは12/11(火)に東京リージョンローンチとなります! 関連情報) みんなのマーケット株式会社:http://www.minma.jp/ Amazon Connect : https://aws.amazon.com/jp/connect/ このブログの作者) Shinsuke Hamamiya(浜宮 真輔) ベンチャー企業を経て2005年に日本IBM入社。金融系の基幹システムにおけるプロジェクト・マネジメントに携わる。2016年に早稲田大学大学院にてMBA取得後、スタートアップ支援とオープン・イノベーションを促進するIBM BlueHubを担当。2018年よりAmazon Web Service Japan, K.K […]

Read More
mamari_nagai

コネヒト株式会社で「ママリ」におけるAmazon Auroraの活用に関するお話を伺いました

こんにちは、Startup担当SAマネージャーの篠原英治(@shinodogg)です。 コネヒト株式会社でインフラエンジニアをされている永井さん(@shnagai)に、Amazon Aurora MySQLへの移行およびその後の運用に関するお話を伺いました。 永井勝一郎(@shnagai)さんについて インフラエンジニアとしてAWSを日々活用し、直近では、ママ向けQ&Aアプリ「ママリ」におけるAmazon ECSを用いたコンテナ化や、Amazon Auroraへのデータベースの移行などを手がけられています。2児の父として、週末はお子さんのサッカーに帯同しながら審判をご担当されることもあるそうです。 Amazon Auroraに移行しようと思った背景 Amazon RDS for MySQL のマルチAZ配置を利用している中で、スタンバイインスタンスにかかっていたコストが気になっていたことと、Amazon Aurora MySQLについて調べていくうちに、リーダーエンドポイントやクローン作成など魅力的な機能が豊富であることがわかり、検証してみたところ手応えを得ることが出来たこと、という2点を挙げていただきました。 どのようにAmazon Auroraに移行しましたか? Auroraリードレプリカを利用したデータ移行の方法を選択。元々MySQLに親しみのあったエンジニアにとっては、この機能を使ったマイグレーションは直感的で、検証段階から躓くことなく取り組むことが出来た、とのことでした。 移行作業において、どのような点に最も気を遣いましたか? データベースのダウンタイムを最小化することに焦点を当てつつ、データのロストが発生しないようAmazon RDS for MySQLへの書き込みを止めて、レプリカラグが無くなったことをもってアプリケーションの接続先をAmazon Aurora MySQL側へ切り替え。今回のデータベース移行はアプリケーションのロジックには全く変更を加える必要がなかったこともあり、移行作業そのものは滞りなくスムーズに予定通りに完了。”事前にしっかり検証出来ていたこともあり想定外のトラブルは全く発生しなかった”とのことでした。 ※ こちらの移行作業の詳細については、永井さんが執筆されたRDS for MySQLからAuroraへの移行 〜Auroraリードレプリカを利用した低コスト移行方式〜 – コネヒト開発者ブログを是非ご覧ください。 Amazon Auroraへ移行したことでのメリットはどのようなものがありますか? スタンバイインスタンスの台数が減ったこともあり、金銭的なコストメリットがありました。また、短時間でクローン作成できることで、今まで長時間かけてスナップショットからリストアして行っていた検証作業をすぐに行うことが出来るようになり、運用にかかる時間的コストも抑えることが可能になりましたね。そして、Amazon RDS for MySQLの際はデータベースのパフォーマンス低下を懸念して導入を断念していた監査機能をAmazon Aurora MySQLによって追加することが出来たことが挙げられます。更に、バッファープールキャッシュのウォームアップにより、”以前はデータベースを再起動する際に自身でウォームアップさせてから投入といったことを行っていたため、そういった手間がかからなくなったことも嬉しい”とおっしゃっていました。 現在取り組んでいることについて コンテナ化できていない部分にAWS Fargateを導入することを検討していたり、機械学習基盤における、運用も含めたソフトウェアのライフサイクル全体の属人化を解消をすることも視野に入れたAmazon SageMakerへの移行に取り掛かっていらっしゃるそうで、ママリの今後の展開も非常に楽しみですね! Startup Architecture of the Year 2018のファイナリストとしてご登壇いただきましたが、いかがでしたか? “エンジニアの方とお会いする際に『見ました!』と声をかけていただくことがあり、AWS Summit Tokyoというイベントの影響力の大きさを実感しました。登壇できて良かったです。” 愛読している技術書はありますか? “ウェブオペレーション――サイト運用管理の実践テクニック を定期的に読み返して、インターネットサービスのインフラストラクチャに携わるエンジニアとして、円滑にオペレーションを回していくためにどのように振る舞っていくべきかを再確認しています。” […]

Read More