まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:softlayer

読売新聞社様主催のジャイアンツハッカソン、4月27日に決勝に残ったチームによる最終審査が行われました:
http://www.giants.jp/G/gnews/news_3910572.html

2016042801



ITを通じてファンと球団との距離を縮め、試合観戦などをより楽しむことができるようなアイデアを広く募集し、アイデアを詰め、短期間で開発し、その出来栄えや実用性、ビジネス性を競い合う、というコンテストでした。数多くの独創的なアイデアや製品が生まれましたが、その中でもコミュニケーションツールを活用して選手をより身近に感じてもらうサービスを発表した "TEAM PAAK" チームが最優秀賞に輝きました。TEAM PAAK の皆様、おめでとうございます。また同ハッカソンに参加された多くの皆様、データ提供や審査などに参加頂いた協賛企業の皆様、大変お疲れ様でした。

同ハッカソンではアイデアを実現するためのお手伝いとして、データスタジアム様や読売巨人軍様から各種データ(試合/打席/投球/選手のデータや画像、球団グッズの売上記録など)を提供いただき、ハッカソン内で利用させていただきました。日本アイ・ビー・エムはサムライインキュベート様と共同で同データをアプリケーションから利用できるよう、各種データを API 化し、クラウドサービス(SoftLayer & Bluemix)と合わせて参加チームに提供しました。この「各種データの API 化」という部分のお手伝いをしたこともあり、この部分を少し掘り下げて紹介させていただきます。

簡単にいうと、データを提供する側の都合と、データを活用したい側の都合をあわせるための場を提供させていただきました。試合の記録データは本来有料で企業に提供されているもので、このハッカソンでの利用に限り、参加チームへは無料で提供いただきました。画像データや売上記録については、これら自体は売りものではありませんが、権利関係などで本来は公開されていないものを含めて提供いただきました。データを使う側からすると、これらのデータを丸ごと(例えばファイルごと)入手できると嬉しいかもしれませんが、上記のような事情からそういった形での提供は望まれていないものでした。 ではどのようにこれらのデータを提供するか、というのが我々の課題でした。

その答が API 化して、参加チーム毎の利用状況を管理しながら提供するという方法でした。この点についてもう少し詳しく説明します。

まずは「API 化」です。API とは Application Platform Interface の略で、ここでは「ウェブを通じて実行できる関数」という意味で使っています。少しわかりやすく説明すると、例えば「○○年□月△日、巨人戦の1回表。最初の打者の第×球目の結果は?」のような条件を与えて問い合わせをすると、「ピッチャーは●●、打者は■■、0対0、ノーアウトランナーなし、カウント 0-1、外角のスライダーで空振りストライク」のような結果が返ってくる仕組みを REST API と呼ばれる手法で用意しました。

これらのデータそのものはデータスタジアム様や読売巨人軍様から提供いただいているものです。1球毎、1打席ごと、1試合ごとなど、粒度の異なるデータを1年ちょっと全試合分提供いただきましたが、そのデータファイルそのものが流出するリスクは回避したい(つまりデータファイルは参加者に渡したくない)という事情がありました。そのため、上記のような問い合わせ条件にあうデータを取得できるような仕組みをウェブ API として(IBM Cloud を通じて)提供させていただきました。


ではそのようなウェブ API の仕組みをどのようにして短期間で(2日程度で)用意したのか? この答は実は以外とシンプルで、以下の3つの仕組みを組み合わせただけでした:
(0) 提供いただいたデータを全てリレーショナルデータベースに格納
(1) StrongLoop LoopBack を使ってデータベースを丸ごと API 化し、ウェブを通じて読み書き更新削除検索といった REST API を自動生成
(2) API Management サービスを使って (1) で作った API のうち、検索(問い合わせ)の API だけをハッカソン参加者に公開


2016042801


まず準備段階 (0) として、提供いただいたデータはいわゆる「ファイル(オフィスファイル、画像ファイル、テキストファイル混在)」でした。このままでは利用や配布/提供が難しかったため、一旦リレーショナルデータベースなどに全データをロードしました。今回は IBM の SoftLayer クラウドのサーバーを使い、その中にデータベースエンジンを導入して、全データをまとめてロードしました(要するにデータベース化しました)。 技術的にはこれでこのデータベースに適宜アクセスできるような仕組みを用意すれば外部から検索したりできる、のですが、上述の理由からデータベース丸ごとでの提供をするわけにはいかない、という背景がありました。

次にこのデータベースを API 化しました(1)。IBM Bluemix でも提供されている StrongLoop LoopBack サーバーを使うと、各種データベースを指定するだけでその中身を読み書き更新するような REST API を自動生成してくれます。

また自動生成された API には削除したり更新したりできるものもありますが、今回のハッカソンではあくまで参照(問い合わせ) API だけを公開したい、という事情がありました(2)。作成した API をわざわざ無効にする、という方法もありますが、今回はこれも IBM Bluemix から提供されている API Management 機能を使って、実際には問い合わせの API だけを公開し、かつ利用状況も合わせてモニタリングできるような方法にしました。


なお、今回の API 生成で使ったこのような (0) (必要であれば)DB を準備、(1) API 化、(2) API を限定公開して監視 という3ステップについては、以前にこちらのブログエントリで詳しい手順を紹介しています。詳しい手順などはこちらを参照してください:
Bluemix だけで REST API を作成/公開/管理する


「API を用意する」と聞くと、ちと面倒そうな印象を受けるかもしれませんが、IBM Bluemix や SoftLayer 、そして これらから提供されている各種サービスを効率よく使うことで、面倒な作業を簡略化し、目的の API を(仕様書に相当するドキュメントごと)作って公開して管理する、といったことが簡単に実現できてしまいます。 もちろんデータベースの操作に慣れた方からすると、直接データベースを扱えた方が効率は良かったかもしれませんが、様々な事情を考慮した結果の1つの実現の形として、今回はこのような提供形態とさせていただきました。今回のジャイアンツハッカソンの成功を受け、「このやり方がある程度は正しかったのではないか」と思っています。もちろんまだ改良・改善の余地はあると思いますが、「データを取りまとめて API を提供する」という役割については一定レベルで果たせたのではないかと考えています。 そしてその作業は、上記のように(IBM クラウドを使うことで)結構簡単に実現できるものだと思っています。


2013 年を最後に SoftLayer の記事を書いていませんでした。久しぶりで緊張します。。

2年以上 SoftLayer から離れていましたが、その間に大きな変化を遂げていました。もちろん知ってはいたのですが、自分が使う立場ではなかったため、変化を具体的に実感する機会がありませんでした。

最近、業務にかこつけて仕事で SoftLayer インスタンスを利用してシステムを構築する、という機会がありました。普段 PaaS (と個人環境の仮想 Linux)ばかり触っていたので、久しぶりの IaaS でした。その業務の中で SoftLayer 上の Linux サーバーインスタンスのファイルシステム上に Object Storage のフォルダをマウントする、という環境を構築する機会があったので、作業内容をまとめておきました。

ちなみに今回の作業の参考にしたのはこちらのサイトです:
https://www.change-makers.jp/post/10362

ただ、この作業そのままでは自分の環境では動かなかったので、あくまで自分の環境で動かした時の作業内容を記載しておきます。自分の環境は CentOS 6.7 64bit です。


まず、Swift 互換の Object Storage を Linux のファイルシステムにマウントするには CloudFuse というオープンソースのライブラリ/ツールを使います。

というわけで CloudFuse を導入します。CloudFuse はソースからビルドして導入するので、まずはビルドをするために必要な前提ライブラリを導入します:
# yum install gcc make fuse fuse-devel curl-devel libxml2-devel openssl-devel git

※上記の Change Makers のサイトではこれで前提ライブラリが導入されることになっていましたが、自分の環境ではビルドに失敗してしまいました。結果として以下のこの処理が足りませんでした:
# yum install json-c-devel

前提ライブラリが準備できたら CloudFuse (のコマンドラインツール)をダウンロードしてビルドします。ダウンロードは GitHub から最新ソースをクローンします:
# cd /usr/local/src
# git clone https://github.com/redbo/cloudfuse

そして configure して、make して、make install します。これで cloudfuse コマンドが使えるようになります:
# cd cloudfuse
# ./configure
# make
# make install

cloudfuse コマンドを使って Object Storage を利用するには、目的の Object Storage にアクセスするための情報(url, username, password)が必要です。SoftLayer の場合は次の方法で取得します。 SoftLayer のコントロール画面のメニューから Storage - Object Storage を選び、利用中の Object Storage を選択し、その画面内の "View Credentials" と書かれた箇所をクリックします:
2016040201


すると以下のようなアカウントクレデンシャル情報が表示されます。この値を後で使うのでメモしておきます:
2016040202


SoftLayer のインスタンス画面に戻り、ホームディレクトリ上に ~/.cloudfuse というファイルを新規に作成します。その内容は先程確認したクレデンシャル情報を使って、以下の内容にして保存します:
# vi ~/.cloudfuse

username=(Username の値)
api_key=(API Key の値)
authurl=(Authentication Endpoint の値。SoftLayer 以外から使う場合は Public 、SoftLayer のサーバーから使う場合は Private の値にする)

なお authurl に指定する値ですが、この Object Storage のマウント自体は SoftLayer ではないクラウドサーバーやオンプレミスサーバーから行うことができます。その場合は Public と指定されていた方の URL を記載してください。一方 SoftLayer のサーバーからマウントする場合は Private と指定されていた方の URL を記載すると、プライベートネットワークを使った高速接続が出来、かつ SoftLayer 内のインバウンド転送なので追加料金がかかりません。

ここまでできたらマウントします。cloudfuse コマンドを使って、Object Storage のフォルダを SoftLayer インスタンスの /mnt ディレクトリにマウントしてみます:
# cloudfuse /mnt

これでマウントは完了しているはずです。df コマンドで確認してみます:
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2       25G  7.4G   16G  32% /
tmpfs           935M     0  935M   0% /dev/shm
/dev/xvda1      248M   94M  142M  40% /boot
cloudfuse       8.0T  4.2G  8.0T   1% /mnt
↑Object Storage って最大 8TB も使えるのね。。


ちゃんとマウントできています。これで Object Storage が SoftLayer インスタンス上のファイルシステムとして読み書き可能になりました!

画像などメディアファイルを多く扱うようなシステムを構築する場合、パフォーマンスのためにメディアデータはデータベースではなくファイルシステムに格納することも珍しくありません(WordPress とかもそうです)。この場合、アプリケーションサーバーをスケールさせてもメディアを保存するファイルシステムがバラバラになってしまっては意味ないので、メディアを保存する先は Object Storage をマウントした先に指定する方法が一般的です(そうするとマウント情報ごとスケールするので、メディアも共有できるようになる)。 そんなシステム構築ではこんな手法を使う、というサンプルでした。特に SoftLayer + Object Storage 環境であれば、ネットワークも高速で、かつマウントした Object Storage への転送時の追加料金もかからずに構築できるというメリットがあります。


IBM Bluemix を使ったアプリケーション開発コンテスト Bluemix Challenge 2015 一般部門の審査が(ほぼ)終わりました。

審査について詳しくは話せませんが、今年も多くの作品を応募していただきました。チャレンジしていただいた皆様、本当にありがとうございます。

私も審査の一部に携わらせていただきました。審査なので、我々の用意した基準を元に各作品に点数をつけていったのですが、多くのオリジナルアイデアが実際に形になっているのを目の当たりにして、点数を付けることに罪悪感を感じてしまうほどでした(まあ、点数付けましたけどw)。その多くは「これは Bluemix のサービスを使わないと作れないだろう」とか「これは Bluemix じゃないと作るの大変だろうな」と感じるほど、Bluemix の提供するサービスや API、外部 API をふんだんに取り入れて開発していただいたものでした。

中には我々が全く想定していない API の使い方をしているようなものもあって、自分の脳がいかに凝り固まっているのかを感じる瞬間もありました。本当に審査していて楽しく、そして嬉しさを感じることができました。改めて応募いただいた皆様に感謝申し上げます。


審査結果および各賞は、学生部門の結果とあわせて9月2日(水)にベルサール渋谷ファーストで行われるイベント: SoftLayer x Bluemix サミット 2015 の、基調講演の中(!)で発表させていただく予定です。お楽しみに!
sl


なお、上記で「審査は(ほぼ)終わった」という書き方をしたのですが、これには意味があります。実はこのコンテスト一般部門には IBM 社員も多く応募していました。公平性から一般審査の対象からは除外したのですが、それなりに応募数が多く、埋もれさせるにはあまりにもったいなかったので、IBM 社員限定での裏コンテストを開催しています(苦笑)。普段の業務で関わったことのない若い同僚たちがこの自社サービスに興味を持って自らアプリを作って開発して競いの場に出てくる、、手前味噌ですが、これはいい環境だなあ、と感じました。 こちらの審査は現時点ではまだ完了していませんが、優秀作品は何らかの形で公開させて頂く予定です。

では SoftLayer x Bluemix サミット 2015 をお楽しみに! そして学生部門は引き続き募集中なので、奮ってのご参加お待ちしています。


SoftLayer の仮想サーバーを借りて早一ヶ月、そろそろ無料トライアル終了の日が近づいてきました。仮想サーバーでありながら、それなりのスペックで素に近い CentOS が使えたことから RunLevel 5 で動かし、開発用の仮想デスクトップ環境として使ってきました。ここで開発したサービスについては近い将来に公開予定です。


さて、このシリーズ最後のエントリは SoftLayer 仮想サーバーの契約を終了する手順を紹介します。ともあれサーバーに SSH でログインしてシャットダウンは済ませておきます。ただしサーバーをシャットダウンしただけでは契約終了にはなりません、この点に注意が必要です。

まずは SoftLayer ポータルにログインし、ホーム画面のメニューから "ADMINISTRATIVE" - "Cancel Computing Instance" を選択します:
sl2013102901

契約中のサーバーインスタンスが表示されます。課金対象から外すにはサーバー契約そのものをキャンセルする必要があります。表の一番右の "Cancel CloudLayer Computing Instane" をクリックします。
sl2013102902


サーバーキャンセルについての情報が表示されます。ここを見ると、無料の30日トライアルに関しては「30日目の午前零時(GMT-05:00)の 24 時間前までに終了のリクエストをすること」と書かれています。で、すぐにキャンセルするか("Immediately")、ギリギリまで使ってキャンセルするか("Anniversary Date")を選んで "Continue" ボタンをクリックします。自分は心配性なので前者を選択・・・
sl2013102903


最終確認画面が表示されるので、内容を確認した上で "Final Confirmation" をクリックします。
sl2013102904


まだ "Final" ではなかった模様(笑)、最後の最後に確認ダイアログが表示されます。ここで "OK" をクリックするとキャンセル処理が実行されて元に戻せなくなります。今までありがと~
sl2013102905


この画面が表示されれば仮想サーバーのキャンセル処理が完了です。
sl2013102906


再度同画面を確認してもサーバーは消えているはずです。
sl2013102907


ほぼ同時に利用者アンケートのメールが届きます。めんどくせー、と一瞬思いましたが、よく見ると「抽選で $500 の VISA ギフトカードが当たる」と書かれてますね・・・ これは、これは。謹んでお答えさせていただきますw
sl2013102908

 ↑英語でのアンケートですけど・・ :P


個人的にはどこからでも使えるこの開発環境を重宝していたので手放すのは残念ではありますが、ほとんどクセのない CentOS 環境が提供されていることや、自動プロビジョンの仕組みもあることから、比較的容易に元の環境を再現できると思っています。今後うちの会社のウェブサービスで仮想環境が必要になった際の、特に開発環境の候補として検討させていただきます。


 

SoftLayer をクラウドノードを開発サーバーとして1週間程度使っています(以前のエントリその1その2)。ただ使っているだけだと「快適です」以外にあまり言うことがなくてつまらないので、違う視点から改めて見てみました。ああ申し込み時にこうしておけばよかった、という思うこともいくつか・・・

まずはデータセンター。選択肢としてはワシントンDC、サンノゼ、シアトル、ダラス、シンガポール、そしてアムステルダムとあります。はっきり言って深く考えずにワシントンDCを選んでしまいましたが、よく見たらこんな資料が・・
sl2013101501


ああ、日本のネットワークセンター(品川)から直結しているのはシンガポールとサンノゼだったのか。このどっちかにするべきでした。

そして利用者向けポータルサイトで見つけた "Provisioning Scripts" の設定。
sl2013101502


実はいまだに申込時にどうやるとこれが有効にできるのか、まだハッキリと分かっているわけではないのですが、OS のロード直後に実行させるプロビジョン用のスクリプトファイルを指定できるもののようです。このクラウドノードからURLでアクセスできるところ(要はインターネット上のHTTPアクセス可能なサイト)にこのスクリプトを置き、その中にシェルスクリプト等で最初に行っておきたいセットアップ内容を記述しておけば、OS の起動直後に実行してくれる、というものです。したがって、ここで書いたような yum の実行コマンドを羅列したシェルスクリプトのテキストファイルを指定すれば、起動と同時に実行されて必要なミドルウェア環境が構築できる、ということだと思います。シェルスクリプトで記述できる範囲に限られてしまうとはいえ、すげー便利!

 

このページのトップヘ