DEV Community: zato

Low cost Dynamic Rendering with rendertron on Cloud Run

zato — Thu, 21 Jan 2021 13:46:30 +0000

If you have a single-page application (SPA) and wanna do some SEO for it, Dynamic Rendering is a good option.
Unlike server-side rendering, you can put the web pages on search index without changing server-side code.

Google provides rendertron to achieve Dynamic Rendering.
And there's a deployment configuration of Google App Engine (GAE) in the repository, so you can deploy it easily to GAE.

Actually, I used rendertron with a production application for over six months. It worked well for SEO.
But the problem was the cost.

At that time, the server cost was $1,500 / month, for only rendertron.

Moving from GAE to Cloud Run

I've used Cloud Run for some times and consider moving rendertron to it.

In terms of instance-per-hour cost, Cloud Run is much cheaper than App Engine:

App Engine (F4 instance, 2.4GHz, memory 1GB): $0.26 /hour
Cloud Run (cpu v1, memory 1GB, tier 1): $0.095 / hour

Cloud Run needs a docker image, but Rendertron doesn't have dockerfile now.
I cloned rendertron repository and added Dockerfile:

FROM node:12-slim

RUN apt-get update \
  && apt-get install -y wget gnupg \
  && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
  && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
  && apt-get update \
  && apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 libxtst6 \
  --no-install-recommends \
  && rm -rf /var/lib/apt/lists/*

WORKDIR /rendertron
COPY . /rendertron

RUN npm install
RUN npm run build

ENV NODE_ENV production

CMD ["npm", "run", "start"]

And it needs puppeteerArgs option in config.json:

{
  ...
  "puppeteerArgs": ["--no-sandbox", "--disable-dev-shm-usage"]
}

Also I set cacheMaxEntries to keep cache (config.json):

  "cacheConfig": {
    "cacheMaxEntries": -1
  },

I built docker images with Cloud Build and deployed it on Cloud Run successfully.

nginx configuration

In our case, I need to proxy requests from search engine crawlers to rendertron.

My nginx config is like:

server {
  ...
  location / {
    try_files $uri/index.html $uri @prerender;
  }

  location /static/ {
    expires max;
    add_header Cache-Control public;
  }

  location @prerender {
    set $prerender 0;
    if ($http_user_agent ~* "googlebot|bingbot|yandex|baiduspider|twitterbot|facebookexternalhit|rogerbot|linkedinbot|embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|W3C_Validator|Linespider") {
      set $prerender 1;
    }
    if ($args ~ "_escaped_fragment_") {
      set $prerender 1;
    }
    if ($http_user_agent ~ "Prerender") {
      set $prerender 0;
    }
    if ($uri ~* "\.(js|css|xml|less|png|jpg|jpeg|gif|pdf|doc|txt|ico|rss|zip|mp3|rar|exe|wmv|doc|avi|ppt|mpg|mpeg|tif|wav|mov|psd|ai|xls|mp4|m4a|swf|dat|dmg|iso|flv|m4v|torrent|ttf|woff|svg|eot)") {
      set $prerender 0;
    }

    # WORKAROUND: there's something wrong with accept-encoding: deflate. rewrite accept-enconding header here to avoid it.
    proxy_hide_header Accept-Encoding;
    proxy_set_header Accept-Encoding "gzip";

    if ($prerender = 1) {
      rewrite .* /render/https://$host$request_uri? break;
      proxy_pass https://rendertron-xxxxxxx.a.run.app;
    }

    if ($prerender = 0) {
      rewrite .* /index.html break;
    }
  }
}

Result

I did some tuning such as changing the number of cpu cores and tweaking concurrency.

The result was 10x cheaper than before: $150/month (before $1,500/month)
It's been running without any maintenance for over 3 months.

How I saved $2,000 / month in Cloud SQL for Postgres; point-in-recovery might cost too much

zato — Mon, 18 Jan 2021 10:47:43 +0000

I have a large postgres database for our web application on Google Cloud (Cloud SQL for PostgreSQL).
A few months ago, I found that the storage usage was over 2TB and it costed us around $3,000 / month. I thought this was too much.

Here's the note when I solved this issue.

tl;dr

Disable point-in-time recovery if you don't need it.

This feature uses a lot of storage because it saves write-head log for some period.
It may cause a problem especially when your database has a large table with high frequency of updates.

The option is in Backups section.

Analyze the size of tables

First, I looked at how much storage each table used.

    table_schema    |                table_name                 | row_estimate  |   total    |   index    |   toast    |   table
 --------------------+-------------------------------------------+---------------+------------+------------+------------+------------
  public             | table1                      | 6.7337024e+08 | 205 GB     | 130 GB     |            | 76 GB
  public             | table2                        | 7.2914736e+07 | 11 GB      | 3871 MB    | 8192 bytes | 7497 MB
  public             | table3                                    |  2.826758e+07 | 10 GB      | 5137 MB    | 8192 bytes | 5514 MB
...

You can see that quickly by running a SQL in this link.

The size of the biggest table is ~200GB while the total disk usage is 2TB. This is strange.

Vacuum

I run vacuum full just in case. This command removes deleted rows from disk and frees database space.

But it made no difference in this case.

vacuum full table1;

Disable point-in-recovery

I found point-in-recovery was enabled in Cloud Console.

It says:

Allows you to recover data from a specific point in time, down to a fraction of a second, via write-ahead log archiving.

The large table was a write-heavy table, so it produces a lot of write-ahead log.

I disabled the option and restarted the database:

The usage went from ~2TB to ~200GB. As time goes, it increases a little but it's still lower than 300GB .

Also, the cost dropped dramatically. And the monthly cost went from ~$2,500 to ~$200.

I'm totally happy about this result.

Closing

Point-in-recovery is a kind of backup recovery feature, which enables you to restore your database to any point of time.
It's useful in many cases. But in some case, it may cost you more than it benefits.

Write complex SQL with sub query easily in Rails

zato — Thu, 19 Nov 2020 10:57:20 +0000

In some case, you have to write SQL with sub query clause. For example, when you use group by or window functions.

You can write it in raw SQL. But, if you have a helper method like this:

class ApplicationRecord < ActiveRecord::Base
   def self.from_subquery(relation)
     from("(#{relation.to_sql}) as #{table_name}")
   end
 end

you can write this nested query in ActiveRecord:

class RestaurantViewLog < ApplicationRecord
   def self.history_for_user(user)
     from_subquery(
       from_subquery(
         select('*', 'lead(restaurant_id) over (partition by user_id order by id) as next_restaurant_id')
           .where(user_id: user.id)
       )
       .where('next_restaurant_id is null or restaurant_id <> next_restaurant_id')
     )
   end

It can be composed with other conditions.

RestaurantViewLog
  .includes(:restaurant)
  .history_for_user(user)
  .order(id: :desc)
  .limit(20)

The raw sql of RestaurantViewLog.history_for_user(user) is below:

SELECT
  "restaurant_view_logs".*
FROM (
  SELECT
    "restaurant_view_logs".*
  FROM (
    SELECT *, lead(restaurant_id) over (partition by user_id order by id) as next_restaurant_id
    FROM "restaurant_view_logs"
    WHERE "restaurant_view_logs"."user_id" = 1
  ) as restaurant_view_logs
  WHERE (next_restaurant_id is null or restaurant_id <> next_restaurant_id)
) as restaurant_view_log

Note: Here the nested query is necessary to filter rows with the result of window function next_restaurant_id.

Don't forget `as: :json` when testing JSON API

zato — Wed, 18 Nov 2020 14:52:39 +0000

When you write tests for your JSON API with request spec, typical code is like:

describe 'POST /restaurants' do
  let(:params) { { name: 'pizza foobar' } }

  it 'creates a restaurant' do
    post '/restaurants', headers: headers, params: params
    expect(response).to have_http_status(:created)
    expect(response.parsed_body).to match(
      'id' => String,
      'name' => 'pizza foobar'
    )
  end
end

But this doesn't test the API right, technically.

Because this test sends a POST request with application/x-www-form-urlencoded, not application/json.

Mostly, you expect request body with application/json for JSON API. This code does not simulate requests properly.

So, use as: :json option:

post '/restaurants', headers: headers, params: params, as: :json

I'm lazy enough to avoid passing as: :json every time.

Usually I override those helpers to pass as: :json option by default:

module RequestHelper
  %i[get post patch put delete].each do |method_name|
    define_method(method_name) do |path, args = {}|
      default_options = { as: :json }
      process method_name, path, default_options.merge(args)
    end
  end
end

RSpec.configure do |config|
  config.include RequestHelper, type: :request
  # ...

Validate state transition easily without any gem

zato — Wed, 18 Nov 2020 13:54:42 +0000

Say, you have a model with status field:

class Order < ApplicationRecord
  enum status: [
    :cart,     
    :requested,
    :confirmed,
    :complete, 
    :canceled 
  ], _prefix: true

In some case, you want to put some constraints on status changes. It can change from cart to requested, but can't change from requested to cart, for example.

You can use state machine gems, such as aasm to write validation.

But the gem introduces new DSL to write state transition. It's too much just for validation.

Solution

It can be written with basic ActiveRecord validation this way:

validates :status,
  inclusion: { in: %w[requested canceled] },
  if: -> { status_changed? && status_was == 'cart' }

If you like to write from -> to direction, just use hash:

class Order < ApplicationRecord
  # ...

  {
    'cart' => %w[requested canceled],
    'requested' => %w[confirmed complete canceled],
    'confirmed' => %w[complete canceled],
    'complete' => %w[],
  }.each do |status_from, status_to|
    validates :status,
      inclusion: {
        in: status_to,
        message: " cannot change from '#{status_from}' to '%{value}'"
      },
      if: -> { persisted? && status_changed? && status_was == status_from }
  end

A few notes:

Use if: -> { persisted? ... to avoid validation when creating a model instance in tests
Set customized message because default ones are not friendly