astamuse Lab

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

そうだAsta4dでWebアプリケーションを作ろう(第6回)

FormFlow

最終回は簡単なFormなら本当に簡単に作れちゃうFormFlowについて書いていきます。
複雑なFormも作れますが、複雑なFormは複雑な処理になってしまうので、ここでは触れないこととします。
興味がある方はユーザーガイドとかサンプルとか見てみてください。

実装

例としては名前とメールアドレスを入力してサーバーに送信するFormを例にして解説していきます。
stepはinput -> confirm -> completeという順番で行うものとします。

良くある簡易登録みたいな感じですかね。
流石にデータをDBに入れるとか登録完了メール送信とかはスコープ外です。

URLRule

まずはFormFlow用にURLRuleを作成します。
Ruleは簡単で、同じURLをGET、POSTで作れば良いです。
GETは最初のページ(input)用でPOSTはそれ以降のページ(confirm、complete)用です。

package com.astamuse.blog_sample.rules;

import static com.astamuse.asta4d.web.dispatch.HttpMethod.GET;
import static com.astamuse.asta4d.web.dispatch.HttpMethod.POST;

import com.astamuse.asta4d.web.dispatch.mapping.UrlMappingRuleInitializer;
import com.astamuse.asta4d.web.dispatch.mapping.ext.UrlMappingRuleHelper;
import com.astamuse.blog_sample.handler.TestFormHandler;

public class UrlRules implements UrlMappingRuleInitializer{
    public void initUrlMappingRules(UrlMappingRuleHelper rules) {
        rules.add(GET, "/form").handler(TestFormHandler.class);
        rules.add(POST, "/form").handler(TestFormHandler.class);
    }
}

HandlerとSnippet

基本的な実装はフレームワーク側で提供されているので、必要なものだけ追加実装すれば問題ありません。
それぞれ説明していきます。

Handler

HandlerはClassicalMultiStepFormFlowHandlerTrait<T>を実装します。
Tはクライアント側から来るデータのデータ型を指定します。
データ型については後ほど書きます。

実装については幾つかの必須の実装と任意の実装があります。
軽くメソッドの説明をしてから全部の実装を載せます。

それではまずはメソッドの説明から。

public Class<T> getFormCls();

実装しなければなりません。
T型のクラスを返却すれば大丈夫です。

public String getTemplateBasePath();

実装しなければなりません。
FormのHtmlTemplateのSuffixを文字列で返却します。
細かいルールはHTMLの説明の時に書きます。

public void updateForm(T form);

実装しなければなりません。
クライアント側からのデータが渡ってくるのでDBへの保存などなどデータ型に対する処理を全て行ってください。
ここはconfirmのページからPOSTされた時にのみ呼ばれます。

public boolean treatCompleteStepAsExit();

任意の実装です。
完了画面を最後に表示するかのフラグを返却するメソッドでデフォルトの実装はtrueで表示しないとなっています。
今回は表示するとしたいと思うのでfalseを返却するよう実装を変更します。
ちなみにtrueの場合はURLRuleのPOSTに処理完了後のredirect処理を入れてあげてください。
ルールで設定すれば大丈夫です。

public FormValidator getValueValidator();

任意の実装です。
FormFlowのvalidation処理はBeanValidationで行うようになっていますが、カスタムクラスを実装する場合はここに独自で実装したクラスを返却するようにしてください。
今回はカスタム方法についても紹介するので、作成するクラスを返却するよう実装を変更します。

public TestForm createInitForm()

任意の実装です。
初期のフォームに表示するデータを返却します。
編集のフォームの時は今持っているデータを初期値として描画するや、途中離脱したユーザーに対して書いたデータを描画するといった使い方が出来ます。
今回はそういうのは無しなので、何も値を設定していないクラスを返却するようにします。

そんな実装をするとこんな感じになります。 updateFormは特に今回することがないので実装を省いてます。

package com.astamuse.blog_sample.handler;

import com.astamuse.asta4d.web.form.flow.classical.ClassicalMultiStepFormFlowHandlerTrait;
import com.astamuse.asta4d.web.form.validation.FormValidator;
import com.astamuse.blog_sample.form.TestForm;
import com.astamuse.blog_sample.utils.FormJsrValidator;

public class TestFormHandler implements ClassicalMultiStepFormFlowHandlerTrait<TestForm> {
    public Class<TestForm> getFormCls() {
        return TestForm.class;
    }

    public String getTemplateBasePath() {
        return "/html/form-";
    }

    public void updateForm(TestForm form) {
    }

    public boolean treatCompleteStepAsExit() {
        return false;
    }

    public FormValidator getValueValidator() {
        return new FormJsrValidator();
    }

    public TestForm createInitForm() {
        return new TestForm();
    }
}

Snippet

ClassicalMultiStepFormFlowSnippetTraitを実装します。
ただ、基本的にはすべてinterface側での実装で問題ないため、自分で実装する箇所はありません。

package com.astamuse.blog_sample.snippet;

import com.astamuse.asta4d.web.form.flow.classical.ClassicalMultiStepFormFlowSnippetTrait;

public class TestFormSnippet implements ClassicalMultiStepFormFlowSnippetTrait {

}

データ型

クライアントから来るデータのデータ型クラスについての説明です。
今回のFormでは名前ととメールアドレスをサーバー側に送信するというようなFormなので、データ型としてnameとmailを変数として用意します。

そんな訳で実装しました。

package com.astamuse.blog_sample.form;

import org.hibernate.validator.constraints.NotBlank;

import com.astamuse.asta4d.web.form.annotation.Form;
import com.astamuse.asta4d.web.form.annotation.renderable.Input;

@Form
public class TestForm {
    private String name;
    private String mail;

    @Input(nameLabel="名前")
    @NotBlank
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }

    @Input(nameLabel="メールアドレス")
    @NotBlank
    public String getMail() {
        return mail;
    }
    public void setMail(String mail) {
        this.mail = mail;
    }
}

と、これだけでは説明が不足しているので説明します。

@Form

FormFlowのデータ型クラスにはこのアノテーションが必須です。

@Input(nameLabel="名前")

このアノテーションはHTMLとデータ型の紐づけに必要なアノテーションです。
Inputタグであれば@Input、Selectタグであれば@Selectのようにタグと合わせたアノテーションを付けることで紐づけを行います。
他にもFormで使いそうなアノテーションはそろってるので、用途に合わせて使ってください。

今回、nameLabelを付けているのは、validationのためです。
説明は後ほどしますので、ここでは割愛します。

@NotBlank

こっちのアノテーションはValidation用のアノテーションです。
必要なアノテーションを付けておけば勝手にValidationしてくれるようになっています。
もちろん、Handlerの実装を変更して他のValidationを行うことや拡張することも可能となっています。

Validation

Validationはasta4dで用意しているJsrValidatorクラスがデフォルトでは使用されるようになっていますが、メッセージの形式の変更とか色々行いたいことが多くデフォルトだと日本語の対応も微妙なので、カスタムクラスを作成するようにしてます。 メッセージの変更はcreateMessageクラスの実装を変更すれば良いです。
データ型で設定したnameLabelは引数のfieldLabelに入ってきます。

この実装は必須ではないので、問題なければ実装しなくても大丈夫です。

ちなみにこのValidation機能のためにpom.xmlにhibernate-validatorを追加してあげる必要があります。
細かい仕様などは長くなりそうなので割愛しますので、別途調べていただけますと幸いです。

package com.astamuse.blog_sample.utils;

import javax.validation.Validation;
import javax.validation.Validator;

import org.apache.commons.lang3.StringUtils;

import com.astamuse.asta4d.web.form.validation.JsrValidator;

public class FormJsrValidator extends JsrValidator {

    //@formatter:off
    private static Validator validator = Validation.byDefaultProvider()
                                                    .configure()
                                                    .messageInterpolator(
                                                        new Asta4DIntegratedResourceBundleInterpolator(
                                                            new Asta4DResourceBundleFactoryAdapter("FormFlowValidationMessages")
                                                        )
                                                     )
                                                    .buildValidatorFactory()
                                                    .getValidator();
    //@formatter:on

    public FormJsrValidator() {
        this(true);
    }

    public FormJsrValidator(boolean addFieldLablePrefixToMessage) {
        super(validator, addFieldLablePrefixToMessage);
    }

    @SuppressWarnings("rawtypes")
    @Override
    protected String createAnnotatedMessage(Class formCls, String fieldName, String fieldLabel, String annotatedMsg) {
        return annotatedMsg;
    }

    @SuppressWarnings("rawtypes")
    @Override
    protected String createMessage(Class formCls, String fieldName, String fieldLabel, String fieldTypeName, String cvMsg) {
        if (addFieldLablePrefixToMessage && StringUtils.isNotBlank(fieldLabel)) {
            String msgTemplate = "%s : %s";
            return String.format(msgTemplate, fieldLabel, cvMsg);
        } else {
            return cvMsg;
        }
    }
}

HTML

今回のHTMLとしてはFormFlowのデフォルトであるinput -> confirm -> completeのフローを表示するため3つ作成します。

htmlファイル名はHandlerのgetTemplateBasePath()で返却するパス+各step名とする必要があります。
今回のケースであればform-input.html form-confirm.html form-complete.htmlと命名したhtmlの作成を行います。

各ファイルの中身はinput、confirmとcompleteで違います。
completeは最終ページなのでただの完了ページとなるため、好きな感じで良いです。 inputとconfirmに関してはルールの元に作成する必要があります。

  • formタグのmethodはPOSTにします
    • actionは設定しなくて良いです(そういうルールですし)
  • form送信時にstepの情報を入れて送信する必要があります
    • 特に表示する必要はないのでinput hiddenで作成します
    • name="step-current"のvalueに現在のstep(input or confirm)を設定します
    • name="step-failed"のvalueにサーバーサイドで失敗した際に行くstepを設定します
      • 今回は元のstepに戻るとします
  • 入力タグのnameでデータ型と紐づくので、nameを設定してください
    • アノテーション、変数名とhtml側の整合が取れている必要があります
  • confirmもinputタグとしていますが、Snippetで自動で置き換わります。nameが同じであれば問題ありません
    • 使いまわさない場合は、idに<変数名>-displayを設定したタグの箇所に描画してくれます
    • 今回は使いまわす形でhtmlを書いています
  • validationエラーの場合は<変数名>-err-msgをidに設定した箇所に描画してくれるので、タグだけ用意しておいてください
    • エラー時の戻り先として"step-failed"に設定した場所に存在する必要があります
  • Snippetの設定は入力箇所を対象となるよう設定してください

とまぁ、こんな感じでルールがあります。
色々と書きましたが、実際のHTMLは簡単です。
上のルールと照らし合わせながら見れば分かるレベルかと思います。

</html/form-input.html>

<html>
<head><meta charset="utf-8" /></head>
<body>
<div>
  <form method="POST">
    <div>
      <afd:embed target="/html/formContent.html"></afd:embed>
      <input type="hidden" name="step-current" value="input">
      <input type="hidden" name="step-failed" value="input">
      <button type="submit" name="step-success" value="confirm">送信
      </button>
    </div>
  </form>
</div>
</body>
</html>

</html/form-confirm.html>

<html>
<head><meta charset="utf-8" /></head>
<body>
<div>
  <form method="POST">
    <div>
      <afd:embed target="/html/formContent.html"></afd:embed>
      <input type="hidden" name="step-current" value="confirm">
      <input type="hidden" name="step-failed" value="confirm">
      <button type="submit" name="step-success" value="complete">送信
      </button>
    </div>
  </form>
</div>
</body>
</html>

</html/form-complete.html>

<html><head><meta charset="utf-8" /></head><body>
    <div>
        完了
    </div>
</body></html>

</html/formContent.html>

<html>
<head><meta charset="utf-8" /></head>
<body>
  <afd:snippet render="TestFormSnippet">
  <ul>
    <li>
      <span>名前</span>
      <div>
        <p><strong id="name-err-msg"></strong></p>
        <input type="text" placeholder="名前" name="name">
      </div>
    </li>
    <li>
      <span>メールアドレス</span>
      <div>
        <p><strong id="mail-err-msg"></strong></p>
        <input type="text" placeholder="test@astamuse.com" name="mail">
      </div>
    </li>
  </ul>
  </afd:snippet>
</body>
</html>

パーツの使いまわしについては機能的な紹介のために使用しましたが、実際の使用場面では別々になるかと思います。
しかし、そこもasta4dの良さをそこなわず対応することが可能となっていますので、

最後に

これで基本的なところは全て解説できたかと思います。
結構使いやすいフレームワークだと思いますので、興味を持った方はぜひとも使って世の中に広めていただければと思います。  

【モバイルフレンドリー対応:実例紹介】デザイナーが最低限考慮するべき3つのポイント

f:id:astamuse:20170801184442p:plain

アスタミューゼデザイン部のMatsumotoです。
早いもので2017年も折り返し。
弊社では、半年に1回人事考課があり、ちょうど先日2017年上期プロジェクトの振り返りを行っていました。

今回のエントリーでは、その考課期間に行ったastamuse.comのモバイルフレンドリー対応の一部を紹介したいと思います。

プロジェクト概要

astamuse.com 「モバイルフレンドリー対応」プロジェクト

現在8月9日時点の対応範囲

  • 技術一覧
  • ヘッダー&フッター
  • 技術詳細ページ
  • キーワード詳細ページ

背景

年々増えてくるモバイルからのトラフィックと、Googleがスマホ対応が不適切なサイトの検索順位引下げ発表により、リリース当初(2012年)はPC環境で使われることを想定してデザインしたastamuse.comもその状況を無視できなくなり、アクセス数が多いコンテンツからモバイルフレンドリー対応を行うことになりました。

年々増えていくモバイルトラフィック (astamuse.com全体の割合)

2012年 15%
2013年 15%
2014年 22%
2015年 27%
2016年 32%

目標

  • Googleのモバイルフレンドリーテストのアラートすべてクリアして、モバイルフレンドリーの基準を満たす。
  • 社内でユーザビリティーテストを行い、UXの向上を確かめる評価をもらう。

効果

  • モバイルフレンドリー対応により、各数値(滞在時間、直帰率、離脱率)の改善。
  • 検索順位UPにより、モバイルからのトラフィック増加。

はじめに

デザインをスタートさせる前に、まずは、Google Search Consoleのモバイルフレンドリーテストで現状把握。
みごと、モバイルフレンドリーテストで失格。

f:id:astamuse:20170727145353p:plain

エラー項目
  • テキストが小さすぎて読めません
  • コンテンツの幅が画面の幅を超えています
  • クリック可能な要素同士が近すぎます

上記エラーをひとつひとつクリアにしていくために実践した、最低限考慮すべき3つのポイントを紹介していきます。

ポイント1:ベストなフォントサイズにする

まずは、エラー項目「テキストが小さすぎて読めません」の対処。モバイルフレンドリーにおけるベストなフォントサイズを調べることからスタートしました。

技術詳細ページ(公開公報本文)の文章は長い、長い。
同じようにコンテンツのテキストが長いサイトといえば、ニュースサイト。参考にさせていただきました。 結果、長文が読みやすいなと感じたサイトの多くは基本フォントサイズは16pxでした。

ちなみにGoogleが推奨するフォントサイズも16px。
一番小さいサイズの推奨は12pxです。

body {
  font-size: 16px;
}

.small {
  font-size: 12px; /* 75% of the baseline */
}

.large {
  font-size: 20px; /* 125% of the baseline */
}

引用/参考: 読みやすいフォント サイズを使用する  |  PageSpeed Insights  |  Google Developers

弊社も世の中の読みやすいとされるフォントサイズに習い、本文のフォントサイズは最適とされる16pxにしました。
行の高さ1.75、1行の文字数は21文字に。(こちらも、他サイトを参考にベストな値で調整)

f:id:astamuse:20170727152416p:plain

ポイント2:リンク範囲と間隔のベストバランスを見つける

次に、エラー項目「クリック可能な要素同士が近すぎます」の対処。
スマートフォンは画面が小さいため、設置したリンクとリンクの間隔が十分にないと、指でタップする際に、うまく押せないことが多々あります。

具体的には、ページ上に密接して配置されている「ブックマーク」と「PDF」のボタンの箇所が、エラーを引き起こしていたと思われます。 ということで、クリックしやすいように、下記2点を考慮してデザインしていきました。

  • リンク範囲は大きくとる
  • リンク同士を近づけすぎず、十分な間隔を確保して、押し間違えを防止する(水平方向と垂直方向で5ミリ(32CSS ピクセル)以内に他のタップターゲットを配置しない)

f:id:astamuse:20170727124529p:plain

参考: Size Tap Targets Appropriately  |  PageSpeed Insights  |  Google Developers

ポイント3:コンテンツの幅に要注意

次に、エラー項目「クリック可能な要素同士が近すぎます」の対処。
スマートフォンの画面からはみ出している場合、このようなエラーがでます。 左右にスクロールしなければならない状態は、モバイルフレンドリーではないと評価されてしまうので、要注意。

さて、問題の箇所はどこだったかというと、ドロップダウンメニューの箇所。 タップのしやすさとタップゲートの間隔を十分にとったモバイルフレンドリーなUIに変更しました。

f:id:astamuse:20170727122724p:plain

参考: Size Content to Viewport  |  PageSpeed Insights  |  Google Developers

結果

  • Googleモバイルフレンドリーテストのエラーすべてクリア。モバイルフレンドリーの基準満たす。
  • 直帰率改善(3.17%減)
  • 離脱率改善(1.63%減)

※技術ページ・モバイルトラフィックのみに絞って計測(リリース前後1ヶ月で比較)
※直帰率、離脱率の数値については、非公開とさせていただきます。

数値の結果は、なんとも微妙でわずか数パーセントの改善のみ。 引き続き定点観測していき、継続して改善していく必要がありそうです。

ただ、目標の一つであった、Googleモバイルフレンドリーの基準はひとまず満たすことができたので、最低限の課題はクリアできたと思っています。

f:id:astamuse:20170727154928p:plain

また、社内のレビューは好評でしたので、実際のユーザーさまの声もぜひ聞かせていただけると嬉しいです。

日頃アスタミューゼをお使いのユーザーの皆さまへ

スマートフォン向けに新しくなったastamuseの技術ページをご覧いただき、読みやすさ、使い心地などのご意見・ご感想などTwitter@astamuseLabにお寄せいただけると嬉しいです。

先月世の中で話題となった特許より、astamuse.com技術ページのリンクをご紹介させていただきます。 ぜひスマートフォンにてご覧ください。

バーチャルホームロボット「Gatebox」

21世紀の“2次元の嫁?”として注目のバーチャルホームロボット。

参考: 【特許取得のお知らせ】Gatebox、「キャラクターとの対話関連技術」に関する特許を取得|Gateboxのプレスリリース

特許のたまご

卵かけご飯に合う卵として7年かけて開発。

参考: 開発7年「卵かけご飯に合う卵」、東日本で先行発売 - ITmedia ビジネスオンライン

Linuxでディスクキャッシュとして使える「bcache」を試してみた

こんにちは。並河(@namikawa)です。

最近、すっかり暑くなってしまって、夏本番って感じですね。夏といえば、海に花火にラーメンと、楽しみが盛り沢山でワクワクしますね!

さて、弊社では多くのデータストアを持っておりますが、クラウドサービス上で大容量なディスクと高い性能を両立させようとすると、(費用的な意味での)コストが一気に跳ね上がることもあり、色々な工夫を試行錯誤しながらやっております。

一定量のホットデータがはっきり見えている前提であれば、高速なストレージデバイスをキャッシュとして使うことは定石であり、キャッシュと一括りにしても様々なレイヤで技術実装されています。

今回はその中でも比較的低レイヤとなるハードディスク等のディスクアレイのようなブロックデバイスに対するキャッシュとして動作する bcache について簡単な性能検証を行なってみました。

bcache とは

概要的な情報を以下に箇条書きします。

  • Linux kernel に組み込まれている
    • バージョン 3.10 以降で利用可能
  • 特定のデバイスを他のデバイスのキャッシュとして利用することが可能
    • 上位レイヤはキャッシュの存在を意識する必要がない (トランスペアレント)
  • write through / write back のサポート
  • 複数のデバイスを扱うことが可能
  • デフォルトではシーケンシャルI/Oアクセスのキャッシュをスキップ (変更可)
    • ハードディスクの苦手なランダムI/Oに絞ったキャッシュ
  • レイテンシをモニタリングし、キャッシュアクセスが輻輳する場合、バイパスさせることもできる (変更可)

尚、bcacheのようなキャッシュデバイスに関する類似的な実装としては、dm-cache、Flashcache、EnhanceIOなどが挙げられます。

インストール・設定

それでは、実際に使ってみましょう。

今回は、GCE上のUbuntu(16.04)のインスタンスを使ってみました。とはいっても、上述の通り、Linux kernelに組み込まれているので、基本的には bcache を扱うためのツールをインストールして、設定を行なっていく感じになります。

バッキングデバイスにハードディスク(/dev/sdb, 500GB)、キャッシュデバイスにSSD(/dev/sdc, 300GB)を利用しています。

ハードディスクとSSDの容量がアンバランスに見えますが、今回は性能的なベンチマークを行うため、あえてIOPSに一定の差がつくような環境にしています。

# apt-get install bcache-tools

まずは bcache を扱うためのツールを apt でインストールします。

# wipefs -a /dev/sdb1
# wipefs -a /dev/sdc1

必要に応じてパーティションを作成した後、FS等メタデータが残っている場合は、上記のように wipefs コマンドでクリアします。

# make-bcache -B /dev/sdb1 -C /dev/sdc1
UUID:           86758735-1c62-43b3-8673-641f148c0926
Set UUID:       499624a7-c90f-40c1-90da-0c2f33fec267
version:        0
nbuckets:       614398
block_size:     1
bucket_size:        1024
nr_in_set:      1
nr_this_dev:        0
first_bucket:       1
UUID:           bda52f6d-a658-4afa-b27d-8d004b210989
Set UUID:       499624a7-c90f-40c1-90da-0c2f33fec267
version:        1
block_size:     1
data_offset:        16

次に、上記のように make-bcache コマンドで、 "-B" オプションの後にバッキングデバイス、 "-C"オプションの後にキャッシュデバイスを指定すると、 bcache デバイス (/dev/bcacheN) が作成され、アタッチまで行なってくれます。

ここまで来ると、後は通常のデバイスブロックと同じように扱うことができます。

状況の確認等で、よく使う(気にする)ところとしては、

# cat /sys/block/bcache0/bcache/cache_mode
[writethrough] writeback writearound none

上記コマンドでキャッシュモードを確認したり、

# tail /sys/block/bcache0/bcache/stats_total/*
==> /sys/block/bcache0/bcache/stats_total/bypassed <==
21.3M

==> /sys/block/bcache0/bcache/stats_total/cache_bypass_hits <==
1

==> /sys/block/bcache0/bcache/stats_total/cache_bypass_misses <==
0

==> /sys/block/bcache0/bcache/stats_total/cache_hit_ratio <==
24

==> /sys/block/bcache0/bcache/stats_total/cache_hits <==
18

==> /sys/block/bcache0/bcache/stats_total/cache_miss_collisions <==
4

==> /sys/block/bcache0/bcache/stats_total/cache_misses <==
56

==> /sys/block/bcache0/bcache/stats_total/cache_readaheads <==
0

こんな感じで統計情報を確認できます。

ベンチマーク

せっかくなので、上記で作成した bcache デバイスに対して、ツールを使ってIOPS的なベンチマークを取得してみます。

前提条件は以下の通りです。

  • GCE で CPU 8core, メモリ 7.2GBのインスタンスを使用
  • バッキングデバイスにHDD(500GB)、キャッシュデバイスにSSD(300GB)を使用
  • OS は Ubuntu 16.04
  • ファイルシステムは XFS
  • ベンチマークツールは fio を使用
    • size=20G, bs=4k, ioengine=libaio, iodepth=8, direct=1

尚、ベンチマークに利用するデータを適切にキャッシュさせるために、意図的にシーケンシャルI/Oについてもキャッシュにのせるべく、以下の設定を行なっています。

# echo 0 > /sys/block/bcache0/bcache/sequential_cutoff



で、以下がベンチマークの結果となります。

f:id:astamuse:20170802121740p:plain

f:id:astamuse:20170802121748p:plain

表の1行目はハードディスク (500GB) 単体のベンチマーク結果、2行目は SSD (300GB) の結果、3行目は bcache デバイス (write through) の結果、4行目は bcache デバイス (write back) の結果となります。

この結果から、 bcache デバイスは、少なくともランダムI/Oアクセスにおいては、ピュアSSDの性能とまではいかないものの、キャッシュデバイスとして一定の効果をもたらしていることがわかります。

尚、 bcache については、ドキュメントを眺めている限り、様々な設定項目があるので、もう少しユースケースやデバイス・ファイルシステム等の特性を考慮したチューニングを行うことで、また違った数値結果となるかとは思います。

さらに検証したい項目

今回は時間の都合上、本当に試しに使って軽くベンチマークを取ってみました、的なところまでしか検証できていないのですが、今後は以下の項目について確認を進めたいと思っています。

  • GCE環境において、バッキングデバイスに SSD を、キャッシュデバイスに Local SSD を使用したベンチマーク
  • 耐障害性のテスト
  • キャッシュデバイスが急にダウンした際の振る舞い
  • キャッシュデバイスが急に性能低下またはエラーレートが高くなった時の振る舞い
  • キャッシュデバイスのオンラインでのアタッチやデタッチが使えるか

本題

・・・と、随分前置きが長くなりましたが、アスタミューゼでは、エンジニア・デザイナーを大募集中です。特に巨大な技術情報群のデータエンジニアリング基盤をバリバリ整備してみたい方や、巨大な技術情報群を扱ったWebサービスの開発をやってみたい方に関して、本当に明日からでも手伝っていただきたいと心から思っております。

少しでもご興味がある方は、下部バナーの採用サイトやサイドバーにある Wantedly のリンクから詳細をご確認いただいて、まずはオフィスに遊びに来ていただいて、カジュアルに情報交換できればと考えております。どうぞよろしくお願い致します。

Copyright © astamuse company, ltd. all rights reserved.