astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

astamuse.comのcssが崩壊した日(2017/07/14改訂)

2017/07/14更新

主に「抽象的な」と言っている箇所の削除・修正を行いました。

前々回くらいに「cssアーキテクチャのtips」とか偉そうなブログ書いた者ですが、 今回自分のcssを崩壊させてしまいました。まったく笑えない、由々しき事態です。

失敗事例をこういうとこで書くべきなのか悩みましたが、反省と自責の意味を込めて書かせていただきます。

astamuse.comのcssアーキテクチャ

2013年に大幅リニューアルしたastamuse.comのcssアーキテクチャは6つの層で成り立っています。

f:id:astamuse:20170704201421p:plain

※この「widgets」という層ですが、atomicデザインでいう「modules」のようなもので、オレオレ概念です。こいつが後々首絞めます。

例としてデザインを見ていきます。

f:id:astamuse:20170704200020p:plain

このデザインをastamuse.comのcssアーキテクチャで分解していくと、下記のようになります。

f:id:astamuse:20170704200023p:plain

componentsのラベル・ボタン・widgetsの見出し・リストらを、modulesで実装してます。

何ら違和感はないように思えますよね。

少なくとも、このcssアーキテクチャで2013年~2017年まで維持できたという点では「間違いではなかった」はずです。

何が起こったか

本年度より、徐々にastamuse.comのモバイル対応を行っております。

【注釈】astamuse.comの「モバイル対応」方針について

astamuse.comはAsta4Dを使っており、特定のUIをモバイル用UIでオーバーライドすることも容易にできますので、モバイル用cssで「モバイル対応」に取り組んでいます。

.wdg-list-vline は横並びli間に「|」を装飾するwidgets。 f:id:astamuse:20170704200023p:plain

だがしかし!

f:id:astamuse:20170704200025p:plain

モバイルだと上記のようなデザインになり、「vline」という単語が意味不明になってしまいました。utilitiesも同じような事態(.line-bottom, .al-center, etc.. )に・・・。

最悪です。抽象的な概念を取り入れすぎた結果がこれです。

[改訂]「構造と見た目の分離」というcssの基本を軽視した結果がこれです。

反省と今後に向けて

今回反省すべきは

  • astamuse.comプロジェクト(サイトデザイン・制作メンバー含め)に適したアーキテクチャではなく、自分が好きなアーキテクチャを選択してしまったこと
  • 抽象的なclass名をhtmlに書きすぎたこと
  • [改訂] 「構造と見た目の分離」を軽視したこと

の2点です。

このアーキテクチャは、widjets,modulesによって新規・追加コンテンツを作るスピードは確かに上がるのですが、

[改訂]この方法は直感的にwidjets,modulesを組み合わせていくことができるので、新規・追加コンテンツを作るスピードは確かに上がるのですが、

中長期で見たときのスピード(削除・リデザイン)を考えると、本プロジェクトには向いてませんでした。


今後に向けてですが、下図のようなアーキテクチャでリデザインしていこうと思います。 各pageの独立性を持たせており、今度のコンテンツ拡充・削除・変更にも耐えていける設計になるはずです。 (Enduring CSSに近しい思想があるかもしれません。)

f:id:astamuse:20170704213009p:plain

完了時期がいつになるかまだスケジュールをたててませんが、近いうちにまたここで発表できればなと思います。

最後になりますが、astamuse.comの大規模リファクタリングを一緒にやっていただける方や、私のcssうんちく話を聞いてくれる方を切に、切にお待ちしております。

Apache Zeppelin と Spark2 on YARN の連携

こんにちは、データ周りを担当してる朴です。

今日はのデータ分析、可視化ツールで注目されているApache ZeppelinとSparkの連携およびZeppelinのマルチユーザー環境の設定について共有したいと思います。

簡単な紹介

簡単にApache zeppelinの紹介をしますと、Apache zeppelinはwebベースのデータ分析、データ可視化をインタラクティブにできるNotebook系のオープンソースです。
似たようなプロジェクトとしてはJupyter Notebookがあります。

主な特徴としては以下のとおりです。

  • サポートしているバックエンドが豊富
    • ほぼすべてのHadoop エコシステム,JDBCで接続できるRDBをサポート
    • 言語もR,Python,Sql,Scalaなどデータ分析で流行ってる言語はほぼサポート
  • Pluggableなパッケージ
    • 0.7から追加されたHelium機能でサードパーティー制のグラフプラグイン、データインターフェースを追加できる
  • データ分析結果を保存共有できる
    • BIツールとしても使える

Sparkとの連携

Apache zeppelinは様々なデータソースをサポートしてますが、中でもSparkと連携するのが最もベーシックな使い方です。 今回はSpark2.1@CDH5.7.xと連携することを試したいと思います。

  • インストール

公式サイトから2017年6月28日時点での最新バージョン(0.7.2)を落としてくるかソースからコンパイルすることも可能です。

$ wget http://ftp.jaist.ac.jp/pub/apache/zeppelin/zeppelin-0.7.2/zeppelin-0.7.2-bin-all.tgz
$ tar -xvf zeppelin-0.7.2-bin-all.tgz


  • Spark@CDH接続設定

zeppelin_home/confで以下の設定ファイルをコピー

$ cp zeppelin-site.xml.template zeppelin-site.xml
$ cp zeppelin-env.sh.template zeppelin-env.sh

zeppelin-env.shに以下の環境変数を設定

export SPARK_HOME=/opt/cloudera/parcels/SPARK2-2.1.0.cloudera1-1.cdh5.7.0.p0.120904/lib/spark2 // 実際のSparkのホームディレクトリを設定
export SPARK_APP_NAME=zeppelin // これは設定しなくても動く
export HADOOP_CONF_DIR=/etc/hadoop/conf
export MASTER=yarn // sparkをyarnで動かす場合


  • Zeppelinを起動する

zeppelin_home/binで以下のコマンドを叩く

./zeppelin-daemon.sh start

ブラウザでhttp://ホスト名:8080入力して、以下の画面が出ればOK f:id:astamuse:20170622150516p:plain

  • interpreterの設定:Spark

Zeppelinではinterpreterを経由して色んなバックエンドに接続してます。
SparkをYarnで動かすためには以下の設定が必要となります。

右上のanonymousをクリックし、intepreterをクリックします。 f:id:astamuse:20170623163356p:plain

interpreterからsparkを検索して、出てきたsparkのinterpreter画面でmasterにyarnを設定する

f:id:astamuse:20170622152830p:plain

これでSparkをYarn上動かせるようになりました。

  • 軽く動作確認

Zeppelinのホーム画面に戻り、NotebookメニューからCreate new noteを選択して新しいnotebookを作成します。 Default Interpreterはsparkを選びます。

以下のコードを入力して、実行します。

sc.version
res1: String = 2.1.0.cloudera1

sc.master
res1: String = yarn

Spark 2.1がYarnで動いてることを確認しました。

マルチユーザー環境にするには(Multi-user Support)

apache zeppelinは0.6まではマルチユーザー環境のサポートが不十分だったようですが、0.7になってから一気にマルチユーザー関連の機能をいくつかリリースしてありますので、その辺の設定方法を共有したいと思います。
詳細は以下リリースノートのMultiuser Supportをご覧ください。
https://zeppelin.apache.org/releases/zeppelin-release-0.7.0.html

  • ユーザ認証を有効に

デフォルトだとanonymousでログインできますが、これだとzeppelin画面に接続できるすべての人が勝手にnotebookを通して、大切なサーバーリソースを使えてしまうので、あまり望ましくありません。 anonymousログインをfalseにすることでユーザごとのID/PWでログインさせます。 zeppelin_home/conf/zeppelin-site.xmlの以下の2つをtrue -> falseにします。

<property>
  <name>zeppelin.anonymous.allowed</name>
  <value>true</value>
  <description>Anonymous user allowed by default</description>
</property>

<property>
  <name>zeppelin.notebook.public</name>
  <value>true</value>
  <description>Make notebook public by default when created, private otherwise</description>
</property>

zeppelin_home/conf/shiro.ini.templateをshiro.iniにコピーします。

$ cp shiro.ini.template shiro.ini

※ZeppelinはApache shiroを使ってユーザ認証を実現しています。https://zeppelin.apache.org/docs/0.7.0/security/shiroauthentication.html

shiro.iniの中身をのぞいてみるとデフォルトで以下のユーザが設定されていることが分かります。

admin = password1, admin
user1 = password2, role1, role2
user2 = password3, role3
user3 = password4, role2

※id = password, roleのフォーマットで設定されてます。
roleも設定できるので、柔軟な権限設定が出来そうです。

zeppelin再起動します

$ ./zeppelin-daemon.sh restart

再びzeppelin home画面に入るとanynomous代わりにloginボタンが表示されます。
これでnotebookをユーザごとに作成・管理できるようになりました。

user1とuser2でそれぞれログインしてnotebook作ってお互いに相手が作ったnotebookがメニューから見えないことを確認できればOKです。

  • Spark applicationをユーザごとに実行する

上の設定までだとuserは分かれていてもsparkのapplicationは一つを共有することになります。
spark applicationをユーザごとに作成するにはspark interpreterのOptionを
The interpreter will be instantiated Per User in isolated per userに変更する必要があります。

f:id:astamuse:20170622175609p:plain f:id:astamuse:20170622175621p:plain f:id:astamuse:20170622175634p:plain

上記設定をsaveしてrestartすれば反映されます。

user1のapplicationIdを確認

sc.applicationId
res1: String = application_1498098397540_0004

user2のapplicationIdを確認

sc.applicationId
res1: String = application_1498098397540_0005

それぞれ異なるIDが出たので、違うアプリケーションとして動くことが分かります。

以上で、マルチユーザー環境のの設定も完了したので、チームでNotebookを使って作業を進めることができます。

うわっ・・・先月のコスト、低すぎ・・・?Hadoopクラスタのクラウド移行とSparkオンデマンド

福田です。

ゆっくりとカモミールを飲みながらラップトップを叩いています。

3年間お世話になったデータセンターのHadoopクラスタをクラウド環境に移行しました。

クラウドでは従量課金を活かしてコストの最適化を図ることができます。

今回、Cloudera ManagerとJenkinsそれぞれのAPIを使用し、クラスタの起動状態を保証するラッパーと自動停止サイクルを実装することで、透過的なクラスタの起動と停止を実現しました。 *1

アーキテクチャ

f:id:astamuse:20170620122256p:plain

全てを包むWraps

作業環境となるホストに、ラッパーコマンド(以下Wraps)をインストールします。 *2

Wrapsは、状況に応じてJenkins、Cloudera ManagerのAPIを呼び出し、VMインスタンスおよびCDHクラスタの起動状態を保証します。

また、後述する停止サイクルに対して使用中であることを通知するロックファイルの作成と削除を、開始時と終了時それぞれに行います。

hadoop、spark-shell、spark-submit、hive、hbaseなどクラスタを使用する任意のコマンドに対してエイリアスを設定し、Wraps経由で実行できます。

停止サイクル

クラスタとVMインスタンスの停止は、Jenkinsのジョブを定期的に実行することで行います。前述のロックファイルが存在しない場合にのみ停止します。 *3

Sparkシェルの意図しない繋ぎっぱなしや、接続断によるロックファイル残留によりクラスタが稼働し続けてしまうことへの対策として、Sparkシェルに読み込ませるスクリプト(アイドル検知し、自動的に終了する)や、親プロセスがいないロックファイルの定期削除などの仕組みも実装しました。

Wrapsデモ

f:id:astamuse:20170620120357g:plain 実行イメージ:クラスタの起動を伴うsparkシェルの起動

f:id:astamuse:20170620120605p:plain 稼働イメージ:テスト環境より

まとめ

クラスタの起動と停止の自動化により、調整のコミュニケーションや手動でクラスタを停止するという人的作業と使用していない時間のインスタンスコストが消滅しました。

空いた時間でハーブティーを入れています。

*1:実際には使用量に応じた割引などがあるため、利用状況に合わせて適切に見積もる必要があります。

*2:Pythonで実装。内部で、便利で気の利いたCloudera Manager API Clientを使用しています。注意点として、使用しているCloudera ManagerがサポートするAPIのバージョンに合ったクライアントを選択する必要があります。

*3:利便性を考慮して、Wrapsを経由したコマンドの実行完了後に一定のアイドル時間を保証するようにしています。これは、終了時のロックファイルの削除を、リネームによるサフィックスの付与とタイムスタンプの更新という実装に置き換え、一定時間以上経過したサフィックス付きのファイルを削除する処理を定期的に実行することで行います。

Copyright © astamuse company, ltd. all rights reserved.