「絶対失敗しない男」が魅せた。一大プロジェクト完結ストーリー
こんにちは。ブランディングプロジェクトのだーはらです。 久々にインタビューブログをお届けします♪ 今月行われた、前期の成果を評価するAward発表にも受賞された、ある一大プロジェクトにピリオドが。 創業からずっと会社を支えてきた20年間のプロジェクトのヒストリーを振り返り、このプロジェクトを通して得たもの、そして、メンバーたちの苦悩や喜び、成長など、「絶対に失敗しない男」と呼ばれるNO.1 プロジェクトマネージャーの田上さんに語っていただきました。 一大プロジェクトを振り返る 原田：今年の2月に、基幹システムのクラウド移行プロジェクトが完結され、みなさんでお疲れ様会をされましたよね。 そして、今月オンラインで行われたASM（オールスタッフミーティング）にて、このプロジェクト全員が表彰され、田上さんはAward発表※でMVPを受賞されましたね。 改めておめでとうございます！ 【Award****発表とは】 Colorkrew__では半年ごとに、素晴らしい活躍をした人を__Award__に選出して称えています。レベルに応じて、MVP+2__カ月、ゴールド+1__カ月、シルバー__0.5__カ月、ブロンズ_+0.2__カ月の追加賞与が支給されます。_ 田上：ありがとうございます。名誉あるMVPをいただけて光栄です。 これもチーム全員の努力だけでなく、適宜協力してくれた全ての人のサポートがあったからこそ、プロジェクトを完遂することができたと思っていますので、関わっていただいた全ての人にお礼を言いたいです。本当にありがとうございました。 原田：本当にお疲れ様でした。今日はまず、このプロジェクトについて改めて簡単に教えていただきたいです。システムのクラウド移行とは具体的になんでしょう？ 田上：会員管理課金システムのクラウド移行って言えば分かりやすいですかね。 会社が創業された1999年のタイミングでサービスが作られて、2008年に一度リニューアルされました。 そのタイミングで様々な決済手段を導入しています。 正確な数字は言えませんが、数百万のユーザーが登録されている会員管理サービス、約10種以上の決済手段が利用可能な課金サービスを運営する基幹システムです。 日本初で導入した決済手段もいくつかあります。 原田：なるほど。創業時からのプロジェクトなんですよね？20年のプロジェクトってすごい歴史を感じます。 田上：このシステムは、何度かリニューアルを繰り返し、20年近く動いています。 今回、クラウド化をやろう！と検討が始まったのが2018年。当時は、あるエンジニアが一人でクラウド化検討をしていたんですよ。 そこから本格始動したのが2019年4月です。 原田：そこから本格的なクラウド化の始まりってことですね。このプロジェクト一番の山場はどこでしたか？ 田上：山場といいますか、チャレンジだったことはありますかね。 オンプレミス環境の老朽化に伴い、サーバー類の交換をするかクラウド環境に移行するかの選択がありましたが、メリットデメリットを変更した結果、元々うちの会社はクラウドに強いというのもあり、クラウドに移行することに決定しました。 もちろんクラウドに移行するにあたり、AWS、Azure、GCP、ハイブリッド案といろいろと検討しました。 オンプレからクラウドへの移行でしたので、諸々ありましたが、幸いうちの会社はクラウドに強いので、そこは助かりました。 最終的には、AWSにて対応することに決まりました。ただ、kubernetes(クバネテス）の技術を導入したことはチャレンジでしたね。 原田：kubernetesとは？ 田上：Dockerコンテナの管理システムです。 コンテナの展開やスケーリング、そういった管理を自動化するためのソフトウェアと思ってください。 原田：クラウドのAutoScalingみたいなものですか？ 田上：近いですね。AutoScalingはサーバーを素早く簡単に増減できる仕組みですが、kubernetesはもうちょっと色んなことができるというか・・・例えばアプリケーション単位で環境構築が素早く簡単にできるんです。 原田：それのどこが素晴らしいのでしょう？ 田上：システムは大きく分けると7つ異なるURLを持つサービスで構成されています。 アプリケーションごとに利用頻度はもちろん異なるわけですが、オンプレ時代は、アプリケーションごとにサーバーを用意する必要がありました。 AutoScalingだけで解決するとしても結局増減するのはサーバーですから、アプリケーションごとにサーバーを用意する必要性は変わりません。 しかし、kubernetesでは、サーバー群をクラスターという一つの大きなサーバーとして扱い、その上で動作するアプリケーションに自由にリソースを割り当てることができます。 つまりより柔軟にサーバーが提供するリソースを利用することができるわけです。 サーバーとアプリケーションが切り離されているので、いくつかサーバーが停止したとしてもサービスに影響ないという点もよいと思っています。 このプロジェクトを通じて得たもの 原田：このプロジェクトを通してメンバーそれぞれの成長などはありましたか？ 田上：技術的なことであれば、うちの会社で一番大規模なシステムかつレガシィなシステムから最新の環境へのマイグレーションを行いましたので、メンバーみんながクラウドに精通したことですね。 マインド的には、うちは元々バリフラットで上下関係がない社風なのですが、今回のプロジェクトを推進していくうえで、メンバーそれぞれが自分ごととして捉えて、プロジェクトを成功するためにどうすれば、いいのかを考えて行動するようになり、チーム一丸となってプロジェクトを成功させるという気概が感じられました。 去年の流行語である**「ワンチーム」**ですかね。 そのおかげでプロジェクトを完遂することができたと思っていますし、**「自分ごととしてやりきる」**というマインドが持てたことが一番の成長だと思っています。 原田：一人ひとりが「自分ごととしてやりきる」ってとても素敵ですね。 田上：はい。**「これを失敗すると会社やばいぞ！」**と言われていたくらい、トッププライオリティなプロジェクトだったので、みんなそれぞれプレッシャーは大きかったと思います。 原田：このプロジェクトメンバーって、割とメンバーの年齢層も幅広かったように感じますが、その辺はどうでしたか？...EC2からStorage Gateway経由でS3をNFSマウント
こんにちは、インフラ担当の赤川です。 AWSの最新情報（英語版）にて、StorageGatewayを利用してEC2からS3マウントが可能になるとのアナウンスされました。 今回のアップデートにより、これまでの問題が解消できるのかベンチマークを取ってみました。 準備した環境 クライアント 比較するために以下A〜C3つのインスタンスを準備しました。 A.FileGateway経由でS3バケットをnfsマウントしたディレクトリをDocumentRootとしたインスタンス B.s3fsでS3バケットをマウントしたディレクトリをDocumentRootとしたインスタンス C.ローカルディスク内にDocumentRootを配備したインスタンス 各インスタンスにhttpdをインストール。 サーバ毎にDocumentRootを変更。 StorageGateway Gatewayの要件はこちら ・・・なのですが、 読まないで進めたらいつまで経ってもGatewayインスタンスに接続できませんでした。 sshでGatewayインスタンスに接続すると、ご丁寧にvCPUが足りんと警告が。ちゃんと読んでスペックを確認しましょう。 （この画像はCPUでWarningですが、メモリ足りない場合はCriticalが出ていました。） ちなみにGatewayインスタンスへのssh接続ユーザのデフォルトは「sguser」です。 S3 マウントするバケットを事前に作成しておきます。 FileGateway設定 まずはStorage GatewayのメニューからFile Gatewayを作成します。 GatewayのタイプはEC2を選択します。 赤枠で囲ったボタンをクリックするとEC2起動画面が開きます。 どうやらGateway用のAMIが用意されているようです。 前述の注意点を気にしながらインスタンスを作成します。 インスタンスを作成したらFile Gatewayの画面に戻ります。 Gateway IPアドレスを求められるので先ほど作成したインスタンスのIPを指定します。 続いてアクティベートも実行されます。 次にファイル共有の設定を実施します。 作成したGatewayを選択して「ファイル共有の作成」をクリック。 マウントするS3バケット名を入れます。 また、S3へ接続できるIAMロールも設定しておきます。 完了するとmountコマンドまで表示してくれます。 親切ですね〜。 クライアントからGatewayインスタンスには接続できるようにSecurity Groupを適宜設定します。 後はクライアントインスタンスを準備し、httpインストールとDocumentRootをマウント先パスに変更しておきます。 abベンチを実行 マウント先にテストドキュメントを適宜配備し、httpdを起動しておきます。 s3fsやローカルディスクを利用したインスタンスも起動して各自ベンチを取ります。 Gateway経由でS3マウントしたインスタンスの結果 s3fsでS3マウントしたインスタンスの結果 ローカルディスク利用インスタンスの結果 数回ベンチしてみましたが、ローカルディスク利用時と遜色のない結果となりました。素晴らしい。 ただ、GatewayインスタンスがSPOFになることと、Gatewayインスタンスのスペックがそれなりに必要なので、 導入時に適したシステムなのか要検討です。...BIG-IP始めました！
くらまねプロジェクトの湯川です。 BIG-IP始めました！ ISAOはF5ネットワークスジャパン合同会社のクラウドパートナー兼SOCパートナーとなり、同社BIG-IPのパブリッククラウドへの導入と運用を行う『BIG-IP by くらまね』をリリースしました。 ちなみに、クラウドパートナー兼SOCパートナーは日本唯一です！ もちろん、事例もあります！ 共同プレスリリースは下記のURLから。 F5ネットワークスジャパン合同会社 https://f5.com/jp/about-us/news/press-releases/161215-press-release ISAO https://www.colorkrew.com/media/news/2016121501/ BIG-IP by くらまね 『BIG-IP by くらまね』では、クラウド環境下にBIG-IP製品を導入し、BIG-IP LTM・BIG-IP APM・BIG-IP ASMの初期設定・運用開始までの誤検知の確認、適用するシグネチャの精査などのチューニングを行います。 さらに、BIG-IP ASMにおいては、ISAOがセキュリティオペレーションセンター（SOC）を運営し、導入支援・サポート・運用・監視までを一貫して行うWebアプリケーションの保護に特化した運用サービスも利用可能です。 エンタープライズで必要とされるセキュアで可用性の高いクラウドプラットフォームの構築および運用をご希望の方はお気軽にお問い合わせください。 近日セミナーも開催予定です！...AWS re:Invent keynote DAY2
昨日に引き続き、2015/10/8 9:00〜10:30（現地時刻） に行われた keynote 中に発表されたプロダクトをお伝えします。 Amazon EC2 新インスタンス、X1, t2.nano まずは EC2 の新インスタンス。X1 インスタンスは最大 100vCPU！/ 2TB メモリー！。クラウド上の IaaS の利用がインメモリ処理で実行するアプリケーションが増えてきたことに対応。SAP HANA などもターゲット。 ホスト側の CPU は Intel Xeon E7 v3 を採用しています。 t2.nano は 1vCPU / 512MB メモリーというスペック。上記のような要求がある一方で、t2.micro の 1GB メモリーでも大きいよ、というニーズが多いためと思われる。 Amazon EC2 Container Registry (ECR) いよいよ AWS のコンテナサービス利用が本格的になりそうだ。 今まで、docker コンテナで利用するイメージファイルは aws 上で管理、作成などができず、ユーザーが独自で管理する必要があった。 今回のアップデートでフルマネージドとなり、AWS 上でイメージファイルの保存、管理、デプロイが可能になります。 また、AZ を意識した配置、CLI などの提供も始まります。...AWS re:Invent keynote DAY1
2015/10/7 8:30〜10:30（現地時刻） に行われた keynote 中に発表されたプロダクトをお伝えします。 Amazon QuickSight Amazon発の高速で使いやすく、コスト効果の高い BI ツール。 ビッグデータや IoT と言った言葉が飛び交う中、UI/UX 部分に関しては個々で開発が必要でした。 これを使ってデータがあればすぐにでも BI を構築できてしまう代物。 データ解析には新たに「SPICE」という名のエンジンを開発。 また、SPICE からのデータエクスポートはDomo, Qlik, Tableau, Tibco等にも対応予定とのこと。 Amazon Kinesis Firehose すでにプロダクト化されている Kinesis の派生版。今まで Kinesis にてストリームされたデータについて EC2 や S3 ひいては Redshift で利用する際、ユーザーが個々にアプリケーションを開発する必要がありました。 Kinesis Firehose を利用すればストリームデータを直接、簡単に S3 や Redshift にロードすることが可能になります。 QuickSight といい、Kinesis Firehose といい、ユーザーサイドの開発を必要とせず、やりたいことをすぐに実現できるようになります。 AWS Snowball 今回の製品発表の中で一番驚きを隠せないのがこれだ。 今までオンプレミスからクラウドへ移行したい、と思うユーザーにとって最大の障壁の一つであるデータ移行。 このデータ移行を安全に迅速に行えるようになるプロダクトが Snowball だ。 アプライアンス製品として提供され、配送の際発生するヒューマンエラーを排除する、とのことなので、物流としての Amazon のナレッジも生かされていると思われる。 1アプライアンス 50TB で提供され、複数個使用することで 100TB, 200TB と利用することが可能。 今までかかっていたデータ移行のための回線費用などの削減する。...