Movatterモバイル変換

Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのかTIS株式会社アプリケーション開発センター川島義隆Java Day Tokyo 2016 3-E

Javaの機能進化おさらい

Java8● Lambda expression● Method reference● Default methods● Stream API● Optional● Map#computeIfAbsent

Java9● Jigsaw● JShell● HTTP/2● SO_REUSEPORT

シンタックスの進化に目が奪われがちだけれども

設計のやり方もアップデートしましょう

NullPointerExceptionの典型例HttpSession session = request.getSession();User user = session.getAttribute("user");if (user.isAdmin()) {// ...}ここでNullPointerException発生引数なしでgetSessionを呼ぶのでセッションがない場合は空のものが作られる空のSessionの場合、userはnullになる。

Guard against nullHttpSession session = request.getSession(false);if (session == null) {response.sendRedirect(LOGIN_URL);return;}User user = session.getAttribute("user");if (user == null) {response.sendRedirect(LOGIN_URL);return;}if (user.isAdmin()) {// ...}nullガード戦法Java有史以来、最も多く使われている戦術だが、ガードの漏れが検出しにくく、実際それが本番障害の原因としてたびたび登場している

OptionalOptional.empty(value)Optional.ofNullable(value)Optional.of(value)optional.get()optional.orElse(T other)optional.orElseGet(Supplier other)optional.orElseThrow(Supplier exceptionSupplier)ここの間が重要Optionalの生成Optionalから値の取り出し

Optionalの意義User user = Optional.ofNullable(request.getSession(false)).map(session -> session.getAttribute("user")).orElse(new AnonymousUser());if (user.isAdmin()) {// ...}Operation中にnullが出現しうる一連の操作を、Optionalで包みこむこと

Embrace null標準APIがOptional前提で設計されていないJavaにおいては、Optionalを使ってどうAPIを設計しようかと考えるよりも一連のnull発生箇所を包み込むことを主眼において考えた方が実用的である。ラムダの扱いをもう少し工夫した事例http://qiita.com/kawasima/items/744914c2fb0b81686a9c

Default method●インタフェースに実装が持てるようになった●インスタンス変数は当然ながら持てないdefault void forEach(BiConsumer<? super K, ? super V> action) {Objects.requireNonNull(action);for (Map.Entry<K, V> entry : entrySet()) {K k;V v;try {k = entry.getKey();v = entry.getValue();} catch(IllegalStateException ise) {// this usually means the entry is no longer in the map.throw new ConcurrentModificationException(ise);}action.accept(k, v);}}

Use caseミドルウェアパターンRequestTraceMiddlewareAuthenticateMiddlewareRequestwriteLog()setRequestTime()RequestwriteLog()setRequestTime()setUserPrincipal()適用するミドルウェアに応じて、メソッドを追加したい

多重継承できないJavaでは…従来は継承でやるしか無かったので、使う使わざるに関わらず、多くのメソッドを予め用意しておく設計が多いjava.sql.ResultSetは実に、193のメソッドをもつ更新可能ResultSetの機能や、全てのJDBC型のメソッドを持つため。

Mixin using default methodspublic interface Traceable {Logger LOG = LoggerFactory.getLogger(Traceable.class);default void writeLog() {LOG.info(toString());}}こういうインタフェースを用意して、implementsすれば、writeLogメソッドが使えるようになる。

Default methodでインスタンス変数を持てないことへの対策任意のデータを出し入れするインタフェースを用意して、public interface Extendable {Object getExtension(String name);void setExtension(String name, Object extension);}public interface Traceable extends Extendable {default void setRequestTime(Long time) {setExtension("requestTime", time);}}デフォルトメソッドではそのインタフェースとのやり取りをする。

private Map<String, Object> extensions;@Overridepublic void setExtension(String name, Object extension) {if (extensions == null) {extensions = new HashMap<>();}extensions.put(name, extension);}@Overridepublic Object getExtension(String name) {if (extensions == null) {extensions = new HashMap<>();}return extensions.get(name);}It's not beautiful, but pragmatic.実装をこんな感じにすれば、データを持つMixinが実現可能

適用するミドルウェアによってimplementsするインタフェースが決まる。ミドルウェアが要求するインタフェースを動的にMixinできるとよいのでは?

動的mixin予めインタフェースをimplementsしてなくても動的にimplementsして振る舞いを足す。Proxy.newProxyInstance(classloader,new Class[]{ Request.class, Traceable.class },new MixinProxyHandler());

Default methodの呼び出しMethodHandles.lookup().in(declaringClass).unreflectSpecial(method, declaringClass).bindTo(proxy).invokeWithArguments(args);MethodHanldeを使うと、実装してないクラスに対してもdefault methodが呼び出せる。http://qiita.com/kawasima/items/f735ef0c0a9fa96f6eb4

注意事項● Java8のJVM実装では、MethodHandleによるinvokeSpecialは非常に遅い。● 通常のリフレクションの10倍〜100倍のコスト開発時は、試行錯誤するので動的Mixinを使い運用時は、性能を優先し静的Mixinを使う。という戦術がよいのでは。

多重継承できないことに起因する- クラス数の増加- メソッドを沢山持つクラスを抑制できる。Mixinの効能

システム挙動の動的な変更(using REPL)Java8 or 9〜

Use caseアプリケーションの一部サービスを閉鎖し、Sorryページにリダイレクトする503Service Temporarily Unavailable

従来よく見られた設計こんなテーブルを用意し、閉塞するときにはフラグを"1"にアップデートする全リクエストにおいて、この閉塞テーブルを検索するSQLが実行されてしまう…機能ID閉塞フラグ閉塞�

管理用APIを用意するこれは最近のJavaでないとできないわけではないけれども…「閉塞状態であること」を永続化する必要はないのでメモリ内の閉塞フラグを書き換えてやればよいhttps://[host]:[port]/admin/service/close限られた工数で、管理用のAPI用意するのが難しい場合もある�@GETpublic String closeService(@QueryParam String serviceCd) {serviceClosingService.add(serviceCd);return "OK";}

REPLがあれば大丈夫(な日がくるかもしれない)

Enkanフレームワークの擬似REPLenkan> /middleware app listANY defaultCharset (enkan.middleware.DefaultCharsetMiddlewareNONE serviceUnavailable (enkan.middleware.ServiceUnavailableMANY stacktrace (enkan.middleware.StacktraceMiddleware@545872denkan> /middleware app predicate serviceUnavailable ANYenkan> /middleware app listANY defaultCharset (enkan.middleware.DefaultCharsetMiddlewareANY serviceUnavailable (enkan.middleware.ServiceUnavailableMiANY stacktrace (enkan.middleware.StacktraceMiddleware@545872dREPL上からMiddlewareの適用条件を操作できるhttps://enkan.github.io/

Enkanフレームワークの起動・再起動時間REPLからの起動 → 1~3 sec　　　再起動 → < 1secMTTRを短くしようという時代の流れの中で、アプリケーションの起動の速さはより重要になっていくhttp://www.slideshare.net/kawasima/enkankotowarirepl速さの秘密はこちらをご覧ください

JShellはどうなっているのか?●コマンドのカスタマイズはできない●動いているプロセスにアタッチできないhttps://bugs.openjdk.java.net/browse/JDK-8157208Java10では、このあたりが解消するかも。

Try ArtifactJShellの中で、Mavenの依存関係を動的に解決し、その機能を試してみることができる。-> /resolve org.apache.commons:commons-lang3:jar:3.4| Path /home/kawasima/.m2/repository/org/apache/commons/commons-lang3/3.4/commons-lang3-3.4.jar added to classpath->org.apache.commons.lang3.RandomStringUtils.randomAlphanumeric(10)| Expression value is: "peXXUYGin6"| assigned to temporary variable $1 of type Stringhttps://github.com/kawasima/try-artifact　現段階でのJShellカスタマイズ事例

Java9時代の無停止デプロイJava9 〜

Java8までの無停止デプロイServer#1WebApplicationLoad balancerServer#2WebApplication縮退しながら、1台ずつリスタート少なくとも2台の仮想サーバが必要�

Application serverの無停止デプロイ機能ServerWebLogic ServerWebApplication WebApplicationプロダクション再デプロイメント前述のサーバでやっていたことをWebLogic Serverの中で実現するアプリケーションの作りによってはメモリリークが発生してしまう�

ServerJava9時代ProcessWebApplicationProcessWebApplication同一サーバ内で同じポートをListenするプロセスを複数立ち上げ、順次再起動する

SO_REUSEPORT● 複数のプロセスから同じポートをListenできる– 従来は"Address already in use:bind"になっていた● 同じuidである必要がある。● Linux kernel 3.9より利用可能(WindowsではUnsupportedOperationException)

SO_REUSEPORTを使うコードServerSocketChannel serverChannel =ServerSocketChannel.open();serverChannel.setOption(StandardSocketOptions.SO_REUSEPORT, true);setOptionメソッドがJava 1.7からなので、各Webサーバプロダクト(Jetty, Undertow, and so on)は直ぐには呼び出せない

SO_REUSEPORT in Jettyclass ReusePortAvailableConnector extends ServerConnector {public ReusePortAvailableConnector(@Name("server") Server server) {super(server);}@Overridepublic void open() throws IOException {ServerSocketChannel serverChannel = ServerSocketChannel.open();serverChannel.setOption(StandardSocketOptions.SO_REUSEPORT, true);InetSocketAddress bindAddress = getHost() == null ? newInetSocketAddress(getPort()) : new InetSocketAddress(getHost(), getPort());serverChannel.socket().setReuseAddress(getReuseAddress());serverChannel.socket().bind(bindAddress, getAcceptQueueSize());serverChannel.configureBlocking(true);addBean(serverChannel);try {Field acceptChannel = ServerConnector.class.getDeclaredField("_acceptChannel");acceptChannel.setAccessible(true);acceptChannel.set(this, serverChannel);} catch (Exception ex) {throw new IOException(ex);

Falchion container● JVMプロセスのコンテナ● Anotherプロセスが起動するのを待ってから、古いJVMプロセスをKillできる。● SO_REUSEPORTとの組合せで、リクエストをロストすることなく、論理的なアプリケーションの再起動が可能になる。https://github.com/kawasima/falchionexperimental

Falchion ContainerFalchion container architectureJVM real processWebApplicationJVM poolJVM virtual processJVM virtual processJVM real processWebApplicationListen the same port

Monitoring JVM● JMXによるDropwizard Metricsの取得– Request数– Error数– スループット● jstatによるGC Metricsの取得

アプリケーションの再起動がより手軽で身近なものにアプリケーションの再起動 = 一大事当然ながらご利用は慎重かつ計画的に…

JVM auto tuning● JVMのパラメータを少しづつ変えながら、性能の変化を計測する。●最適なものを選択– Full GC countを最小に– 1回あたりのFull GC Timeが最長のものが一番短く(Full GC Timeのマクシミン)JVMコンテナの活用可能性

『柔軟な設計』の変化

これまでに手にした武器●無停止デプロイの気軽さ●高速な起動●システムの挙動の動的変更

課題設定ETC割引の計算ロジックを実装します。– ただし、平日朝夕割引は実際には後日還元なのですが、ここでは他の割引と同じく即時適用かつ走行距離による還元率の変化はないものとします。– 走行記録は、24時間を超えないものとします。https://github.com/kawasima/kata/tree/master/ex01-business-ruleshttp://www.driveplaza.com/traffic/tolls_etc/ より。ルールは簡単のため多少いじっています。

割引ルール●平日朝夕割引– 平日「朝:6時〜9時」、「夕:17時〜20時」–地方部　– 当月の利用回数が5回〜9回 30%割引、10回以上 50%割引●休日割引– 普通車、軽自動車等(二輪車)限定–土曜・日曜・祝日–地方部– 30%割引●深夜割引–すべての車種– 毎日0〜４時– 30%割引

システム運用負荷を下げたいので…できるだけ止めずに

従来の柔軟な設計ルールをRDBMSに登録し、これを読み込んで、割引率を算出する。データを追加・変更すればシステム改修なしに、ルールの追加・変更が可能だ!!ルールIDルール名開始時刻1終了時刻1開始時刻2終了時刻2月曜日フラグ火曜日フラグ　　︙日曜日フラグ走行エリア割引率適用開始日適用終了日ルールID車種コード車種コード車種名ルール許容車種車種

実際運用してみると発生する課題● 1つのルールで、時間帯を3つ以上持ちたいという要件。増えてくカラム。● 用意していない属性(排気量やハイブリッド車優遇など)を使ったルールの追加。増えてくカラム。プログラム改修。● 予期しないデータが入って、Exceptionが発生。増えていく再発防止策。●結局ルールを変更するのも開発チームに依頼してやってもらう運用に…

「自由度の高いシステムを作ったぜ」という思惑とは裏腹に…●高すぎる自由度は、十分にテストするのが難しいことを意味する●特にデータの組合せにテストケースが隠されると、十分なテストが出来てないことが多くなる

再起動が容易であれば…●ふつうにルールの変更にしたがい●コードを書いて●テストを書いて●安全に簡単にデプロイしてしまえばよい。

ルールの実装例public class DiscountInMorningOrEvening implements DiscountRule {private RulePeriod morning = new RulePeriod(6, 9);private RulePeriod evening = new RulePeriod(17, 20);@Overridepublic boolean isApplicable(HighwayDrive drive) {return ((!morning.isHoliday(drive) && morning.isIn(drive))|| (!evening.isHoliday(drive) && evening.isIn(drive)))&& drive.getRouteType() == RouteType.RURAL;}@Overridepublic long discountPercentage(HighwayDrive drive) {int count = drive.getDriver().getCountPerMonth();if (count >= 10) {return 50;} else if (count >= 5){return 30;} else {return 0;}

YAGNI has come to Java運用の大変さ(のイメージ)から、過剰設計になりがちだったJavaの世界も、今必要なものだけを設計し作ればよい時代に

堅い、固い、硬いイメージのJavaも、工夫次第では、時代に合わせて柔軟な運用・設計が可能シンタックスのキャッチアップだけでなく、設計の手法のアップデートもお忘れなく

Movatterモバイル変換

Change Language

Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか

More from Yoshitaka Kawashima

Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか